RFR: bug: Timely Reducing Unused Committed Memory

Thomas Schatzl thomas.schatzl at oracle.com
Fri Sep 7 08:10:40 UTC 2018

Hi again,

On Thu, 2018-09-06 at 20:46 +0200, Thomas Schatzl wrote:
> Hi,
>   some additional comment:
> The specific issue with having a new additional thread is its (stack)
> memory usage which will show up in memory usage benchmarks.
> We could get away without an additional thread if we changed the
> G1ConcurrentMarkThread to do some kind of (regular) polling instead
> of signalling.
> I.e. the G1ConcurrentMarkThread would poll a few status variables
> every now and then, with sleeps inbetween.
> Then it would be possible to start VM operations/GCs within that loop
> easily as both G1ConcurrentMarkThread and VM thread (which runs the
> VM operations) try to lock the same lock.
> This would also allow easy disable/enable of the idle-uncommit
> feature at runtime.
> Btw, if I am not mistaken the current implementation of the idle
> triggering might be a bit surprising: since the _last_heap_resized
> counter is not reset for every gc, there may be unforeseen situations
> where idle is detected while (infrequent) GCs are running.
> Is the current implementation in this way what you expected?

  overnight I thought a bit of the implementation, and given the
problem with heap usage of the new thread, and the requirement of being
able to turn on/off that feature by a managed variable, the best change
would probably reusing the service thread as you did in the initial

Exposing/using another callback to the collector would be least bad;
however a call to some method to the CollectedHeap (or G1CollectedHeap)
should be the only thing that should be in the service thread imho.

Rodrigo, would that be okay for you, and could you take that over
(everything else like putting the functionality in its own class and
files, and making the decisions visible in the log, stays the same)?

Sorry for changing my mind again, but yesterday I just wanted to get
something out for you to look at even with that issue unresolved. :(


More information about the hotspot-gc-dev mailing list