RFC: JEP: ZGC: Automatic Heap Sizing

[Kirk Pepperdine]

Hi Erik,

Some questions.

On the question of allocation stalls, couldn’t/shouldn’t one just start the collection cycles sooner?

On the question of sharing in containers, I’m aware of two different experiments on how to resolve the issue of allowing Java heap to consume more of available memory. Of the two the most interesting is a modification of G1 that uses GC thread CPU overhead as a signal to decide if Java heap should be expanded or contracted. The idea is to keep GC thread utilization within a band (of ~20%). The other component of this experiment is to fail any attempts to expand should that expansion risk triggering an OOM killer. In this case the failed expansion will result in a hotter CPU. That said, this a significantly more graceful degredation than having the process terminated. My question is, would you consider taking a similar approach for ZGC?

Finally, on the flag ZGCPressure, could you speak a little more about how it balances CPU vs memory? Specifically, what does the value 5 represent? I understand if one were to pull on that lever you affect the level of aggressiveness but is this aggressiveness of how quickly heap would be expanded?

Kind regards,
Kirk


> On May 2, 2024, at 7:44 AM, Erik Osterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi,
> 
> I have written a draft JEP for a automatic heap sizing when using ZGC.
> JEP description is available here: https://bugs.openjdk.org/browse/JDK-8329758 <https://bugs.openjdk.org/browse/JDK-8329758>
> 
> Comments and feedback are welcome.
> 
> Thanks,
> /Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20240502/2683737b/attachment.htm>