Runtime.getRuntime().freeMemory() with ZGC

[Per Liden]

On 6/3/21 3:44 PM, Mike Rettig wrote:
> 
> 
> On Thu, Jun 3, 2021 at 5:01 AM Per Liden <per.liden at oracle.com 
> <mailto:per.liden at oracle.com>> wrote:
> 
>     If I understand your use case correctly, it sounds like the option you
>     are looking for is -XX:ZCollectionInterval=<seconds>. This tells ZGC to
>     do a GC at least every <seconds> (where <seconds> can be floating point
>     number). Since pauses are O(1), this effectively means the same
>     thing as
>     "target pause frequency" or "target accumulated pause time per minute"
>     but specified in a different way. ZGC would only collect garbage more
>     often than ZCollectionInterval if it has already grown the heap to its
>     max size and it's still not enough to avoid an allocation stall.
>     However, under "normal conditions" it will grow/shrink the heap to a
>     size that is enough to meet the ZCollectionInterval goal.
> 
>     /Per
> 
> 
> My preference is for a "max" number of collections. If I specified the 
> interval then that would be a min with the actual number of collections 
> being scheduled + high usage + proactive. However if I disable proactive 
> then it might be close enough to what I want but it depends on how "High 
> Usage" collections work. Do "High Usage" collections only consider the 
> overall max heap (-Xmx) and not the current heap?  If the answer is -Xmx 
> then it is probably okay, but if it is the current heap then the 
> scheduled collections are similar to proactive collections in that they 
> just add unnecessary collections.

The "High Usage" rule will start a GC if the current heap usage is 95% 
or more of Xmx (or SoftMaxHeapSize if that is set to something lower 
than Xmx). This as an emergency/backup mechanism, which is meant to only 
kick in if the normal heuristics gets things completely wrong (for 
example, because the allocation rate is super unpredictable) and we're 
heading into dangerous territory. If this rule kicks in, you really want 
to do a GC, otherwise an allocation stall is likely awaiting around the 
corner.

Also note that when setting ZCollectionInterval, a GC cycle will only 
start if the time since the previous GC cycle exceeds the specified 
interval. So, the interval timer will be reset/restarted if a GC cycle 
is started for some other reason before the interval timer expired.

If "Proactive" GCs kick more frequently than the ZCollectionInterval you 
want to use, then disabling it (-XX:-ZProactive) is a good idea.

/Per