Min vs Max vs Soft Memory Limits

Per Liden per.liden at oracle.com
Mon May 24 12:25:12 UTC 2021

On 5/19/21 4:57 PM, Mike Rettig wrote:
> On Wed, May 19, 2021 at 2:53 AM Per Liden <per.liden at oracle.com 
> <mailto:per.liden at oracle.com>> wrote:
>     Hi,
>     On 5/13/21 3:24 AM, Mike Rettig wrote:
>      > Ideally ZGC would provide a set of options so that it knows the
>      > priorities of the application. With G1, this is easy. You specify
>     the
>      > min and max memory and a max pause time target. G1 will adjust
>      > accordingly to meet those goals. ZGC needs something similar to
>     G1's max
>      > pause time. Since the pause time is consistently below 1ms, the
>     pause
>      > time target doesn't make sense. Maybe ZGC needs a pause frequency
>     target?
>     That's essentially what you have today in ZGC, with Xmx and
>     SoftMaxHeapSize. These options control the heap size, which directly
>     correlates with GC frequency.
> Finding the right SoftMaxHeapSize is tedious. It's going to be different 
> based on the hardware and load. Also the number will change as features 
> are added to the application. It would be much easier if ZGC could be 
> configured based on the acceptable limits (min memory, max memory, pause 
> target). Does ZGC use the min memory for anything? IME ZGC immediately 
> uses all the memory up to max.

-Xms guides how much of the heap ZGC should never uncommit.

>      > My goal with ZGC is to pause as infrequently as possible. I think
>     that
>      > is a common goal for developers. ZGC benchmarks often compare the
>     avg
>      > and max pause times compared to G1 but in some cases the overall
>     pause
>      > time for ZGC is greater than G1 because it pauses more frequently.
>     Are you sure you're looking at the right numbers here? If you're on JDK
>     16, then pauses are normally ~50us, so that means ZGC would run GC
>     cycles something like 1000 times more often then G1, which doesn't
>     sound
>     right. Did you perhaps get the accumulated GC time from the
>     GarbageCollectorMXBean? If so, that doesn't show you the accumulated GC
>     pasuse times, but the accumulated time for complete GC cycles. Btw,
>     this
>     was changed in JDK 17 (see https://github.com/openjdk/jdk/pull/3483
>     <https://github.com/openjdk/jdk/pull/3483>).
> I am using jdk 16 and I get my numbers from the safepoints in the GC 
> log. Pauses average 100-200us for each stage (ZMarketStart, ZMarkEnd, 
> ZRelocateStart). If an average collection takes ~500us for all 3 stages, 
> then it can quickly approach the collection time for G1 if the typical 
> G1 pause is 3ms.

Ok, the typical pause profiles I had in mind was 150us (50us x 3) for 
ZGC vs. 150ms for G1.

>      > Recently I've disabled the proactive pauses. Why bother to do a
>      > collection when the heap is 30% full when it can done in the same
>     amount
>      > of time when the heap is at 80%?
>     If you get proactive GC cycles, it means you application is more or
>     less
>     idle, or at least it's not allocating very much. Proactive GC cycles
>     happen for two main reasons:
>     1) Avoid expanding the heap, since an (almost) idle application doesn't
>     need that memory.
>     2) Even if the application is idle for periods of time, you still want
>     Finalizers to run.
> What are the thresholds for an app being idle? IME ZGC appears to be 
> very aggregresive for proactive pauses. I know the app isn't completely 
> idle.  I think there is an assumption that ZGC collections are 
> essentially free so you might as well do them frequently. I still 
> consider them very costly. Stopping user threads should only be done 
> when absolutely necessary.

ZGC doesn't assume proactive GCs are free. It aims to only do a 
proactive GC if the estimated application throughput drops by at most 1% 
over time.

> Does G1 do proactive pauses?  



> G1 pause times increase with the size of 
> the heap so proactive pauses could help G1 stay within the pause target.
> Mike

More information about the zgc-dev mailing list