The Holy Grail: a GC that doesn't need Xmx

alex at alex at
Tue Aug 31 19:37:07 UTC 2021

tl;dr I've read zDirector.cpp and played with options, and realized that ZGC can't simply be told to do one job: Keep garbage to a minimum. Why not?
The schpiel:
It's long been a dream of mine to run Java apps without giving them a fixed block of RAM to eat (similar to how C/C++ and desktop C# apps work). The usual "here is a fixed block of RAM" was ideal on traditional, dedicated servers but is undesirable on the desktop where apps are expected to play nice under the motto "to each according to their needs." Today, even server apps are moving to a swarming-mass-on-one machine model, thanks to Kubernetes.
Java on Kubernetes is still a source of frustration. E.g.:
  - [ ]( )
  - [ ]( )
I don't want this post be about Kubernetes, but juggling Kubernetes soft and hard mem limits, requirements of additional in-container processes, and Java's percent limits, absolute limits, soft and hard limits is non-trivial.
Problems with current heuristics:
- ZCollectionInterval doesn't try to stop an allocation spike (such as during startup) from allocating a lot of garbage (and, generally, doesn't try to balance CPU load vs garbage accumulation).
- A lot of heuristics rely on the value of Max Heap to make decisions, requiring it to be set to a reasonable and small value.
- Allocating more memory than SoftMaxHeap puts the GC in an endless loop and is very sub-optimal.
My proposals:
- Do something else.
- One idea is to make decisions based solely on how the heap is growing. Eg, trigger GC every 10% of heap growth, and when the heap stops growing trigger by timer.
- Another (crazier) idea is to make the GC pluggable so that I could register a zDirector on the Java side and do whatever I want.
- Do anything.
Thank you for your attention,
Aleksandr Dubinsky

More information about the zgc-dev mailing list