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

[Thomas Schatzl]

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