RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory

Thomas Schatzl thomas.schatzl at oracle.com
Wed Nov 14 11:07:14 UTC 2018


On Wed, 2018-11-14 at 10:49 +0000, Sunny Chan, CLSA wrote:
> I think my main concern is that this is a departure from the norm in
> the VM. The use of "peridodic gc" reminds me of the RMI DGC hourly 

Both Shenandoah and ZGC have some sort of periodic GC. Their GC pauses
are of course much lower.

> Full GC saga where it causes random pauses that is not known and
> eventually everyone pretty much disabled it by default. Although it
> is a concurrent cycle and the impact is supposedly small, I suspect
> there will be other unintended consequences and effects that would be
> discovered when we move to production. However I can see that for a
> lot of docker/cloud workload this would be a beneficial.

Thank you for the historical perspective. Maybe it is some case of good
intentions cause havoc, what do others think?

We can disable these periodic GCs by default for now and look at the
adoption rate. It is also opt-in for J9.

> I would suggest that:
> 1) Can you document the -Xmx==-Xms case in the JEP so that it is
> cleared that this has been considered and rejected for a good reason.

Okay, adding a note right now.

> 2) Can you make sure you really highlight this in the Java 12 release
> notes/documentation so that people would not be surprised when the
> periodic GC kicks in?

There will be a JDK 12 documentation update for this JEP. I added this
to the todo list to not forget.

> In terms of the AlwaysPreTouch, I am considering that these are the
> settings used where people who cares about low latency would use, and
> these would indicated that the VM should really stop doing things
> that would cause unintended GC cycle.

I need to think about this, and I am open to suggestions from others.
This exception as any other seems to make the explanation when it
happens rather complicated. Disabling it by default may be the better

> For the question of the good "idlesness" notion I don't think there
> will ever be a good answer. I will sleep on it and if I can come up
> with something I will let you know.

Thank you for your input.


More information about the hotspot-gc-dev mailing list