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

[Sunny Chan, CLSA]

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 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.

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.
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?

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. 

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.

-----Original Message-----
From: Thomas Schatzl <thomas.schatzl at oracle.com> 
Sent: Wednesday, November 14, 2018 6:26 PM
To: Sunny Chan, CLSA <sunny.chan at clsa.com>
Cc: hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory

Hi,

On Wed, 2018-11-14 at 06:48 +0000, Sunny Chan, CLSA wrote:
> In general if someone set –Xmx and –Xms to the same value we generally 
> won’t want the GC to release memory back to the operating system as we 
> actually need this for some reason (e.g. low latency).
> Can we disable the periodic GC if someone set –Xmx and –Xms to the 
> same value?

I considered automatically disabling the periodic gcs in this case (- Xmx==-Xms), however I decided against it at the time of proposing this change. The reasons are:

- there are other non-Java heap memory resources that may need cleanup (interned strings, ...) that would otherwise linger around for potentially a long time, causing (native) OOME. See e.g. JDK-8213198 which this periodic GC also helps with.

- soft references in my view will work more naturally, "decaying" over time as expected regardless of GC activity.

- in general, all kinds of java.lang.ref.Reference instances will be "regularly" cleaned up.

If -Xmx == -Xms is set, the Java heap size will never change. I.e. the uncommit respects existing heap resizing mechanisms. This change simply reuses the mechanism introduced in JDK-6490394.

Then there is the question of enabling this by default or not: overall it seemed to be the safer approach given e.g. JDK-8213198 as the disruption seems tolerable for the majority of use cases even when the user sets -Xms==-Xmx.

There is the option to disable periodic GCs completely with
-XX:G1PeriodicGCInterval=0 if your use case requires it.

> Also if someone use “-XX:+AlwaysPreTouch” in general they would be 
> sensitive to the os page allocation latency, and we should consider 
> whether should be candidate for this memory utilization optimization 
> when the option is used.

I do not completely understand this suggestion, can you clarify? Do you suggest that using -XX:+AlwaysPreTouch should also automatically disable this feature due to memory latency concerns?

Not sure actually - given that -XX:+AlwaysPreTouch is typically paired with -Xms==-Xmx this does not seem to be an additional problem.

We do not recommend to use -XX:+AlwaysPreTouch without -Xms==-Xmx (if you care about latency); otherwise you already deliberately opted in to suffer from these latency spikes even outside of the occurrences of the periodic gcs.
Since these periodic gcs are supposed to occur when the "VM is inactive" I would not expect additional latency introduced by -XX:+AlwaysPreTouch to be of any particular further issue.

There is JDK-8210709 to in some specific cases improve the -XX:+AlwaysPreTouch overhead too.

I understand that in the _very_ low-latency case, you probably tightly manage the resources that this periodic GC would help clean up. So the default notion of "VM is idle" is probably incorrect, and the periodic gc actually not required or desired.

We can improve this "idleness" notion (even right in this review) if we can agree on a good metric (e.g. amount of code executed? "no" other native memory allocations?) with some particular properties (fast to check, hopefully already gathered somewhere in the VM, has ideally no or very few false positives).

However overall I am not sure if the very low-latency case to be that common to be considered kind-of default. Moreover, in this case I would not rely on any heuristics (where do you set the boundary of idle in case of amount of code executed; what is "idle" native memory
allocation?) and just turn off the feature instead of trying to configure it to fit.

Appreciate your feedback.

Thanks,
  Thomas



The content of this communication is intended for the recipient and is subject to CLSA Legal and Regulatory Notices.
These can be viewed at https://www.clsa.com/disclaimer.html or sent to you upon request.
Please consider before printing. CLSA is ISO14001 certified and committed to reducing its impact on the environment.