SoftMaxHeapSize vs Periodic GC

[Ruslan Synytsky]

Hi all, I would like to share our conversation with Per Lidén about
SoftMaxHeapSize implementation. We believe some people might find it
useful.

What is the major difference between *-Xmx5G -Xms2G -XX:ZUncommitDelay=10 *
>>>> and *-Xmx5G -XX:SoftMaxHeapSize=2G? *As I understand the both configs
>>>> will try to keep memory usage at 2G or below.
>>>>
>>>> Not quite. The first configuration will happily grow the heap to 5G
>>>> every GC cycle, and then fairly quickly (10s) uncommit any unused memory.
>>>> The second configuration will not grow the heap beyond 2G unless it's
>>>> really needed (to avoid OOME or an allocation stall). So, if the
>>>> application runs well with a 2G heap, the first configuration will still
>>>> let the heap grow to 5G and then collect garbage,
>>>>
>>> Will not ZUncommitDelay release the memory quickly / aggressively, so
>>> the heap does not grow to 5G?
>>>
>>> Yes (to the first part) and no (to the second aprt). ZUncommitDelay
>>> controls uncommit aggressiveness. However, for memory to be uncommitted it
>>> must first become unused, i.e. garbage collection must have moved objects
>>> out of that region/zpage. If the Xmx is 5G and no SoftMaxHeapSize is given
>>> (it defaults to Xmx), then the GC will typically fill up the heap to
>>> about 5G before collecting garbage.
>>>
>> Hi Per, do you mean that the heap will not be scaled down till it gets
>> fully filled?
>>
>> In ZGC, the uncommit mechanism (which executes in a separate background
>> thread) can uncommit memory whenever it finds unused memory. However, for
>> memory to become unused a GC needs to happen first. How often a GC happens
>> depends on the configuration, but generally speaking, a GC is by default
>> started when you're out (or almost out) of memory (i.e. the heap is full).
>> You can use various flags to change this behavior, like SoftMaxHeapSize,
>> ZCollectionInterval, etc.
>>
>> At this point some memory becomes unused and can be uncommitted. However,
>>> if you set SoftMaxHeapSize to e.g. 2G, then the GC will only fill up the
>>> heap to 2G before initiating a GC cycle. And of course, any memory that
>>> became unused after that cycle can then be uncommitted.
>>>
>>> So, Xmx and SoftMaxHeapSize controls how large the heap can grow.
>>> However, then uncommit mechanism has no direct relation to that. It only
>>> cares about unused (collected) memory
>>>
>> Hope that clarifies things.
>>>
>> Yes, the additional clarification helps. Looks like the situation with G1
>> is different as we use G1PeriodicGCInterval for scaling the heap down and
>> the GC will not wait till the heap gets filled up to Xmx. So I assume that
>> the same question for G1
>> *What is the major difference between -Xmx5G -Xms2G
>> -XX:G1PeriodicGCInterval=1000 and -Xmx5G -XX:SoftMaxHeapSize=2G?*
>> will have a different answer compared to ZGC. In G1 the both combinations
>> will give more or less the same result. Are these statements correct?
>>
>> Note that ZGC has this option too, it's called
>> -XX:ZCollectionInterval=<seconds>. The big difference between these is
>> that one is time-based and one is size-based. With G1PeriodicGCInterval/ZCollectionInterval you
>> have no direct control over how much the heap will grow during the given
>> interval. SoftMaxHeapSize gives you that control. Also note that you can
>> enable both in ZGC. Whichever condition is met first will trigger a GC.
>>
>
Also, I have a speech about the state of Java elasticity next week where
I will highlight the recent (G1PeriodicGCInterval/ZCollectionInterval,
SoftMaxHeapSize) and the further (JEP 387: Elastic Metaspace)
improvements. I might miss some other work that already enhanced or will
enhance Java elasticity. Please let me know if you think that a specific
improvement or a bug fix should be added to the presentation.

Regards
-- 
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS <https://jelastic.com/>