The Holy Grail: a GC that doesn't need Xmx
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.: - [ https://blog.arkey.fr/2020/10/27/maxrampercentage-is-not-what-i-wished-for/ ]( https://blog.arkey.fr/2020/10/27/maxrampercentage-is-not-what-i-wished-for/ ) - [ https://stackoverflow.com/questions/49854237/is-xxmaxramfraction-1-safe-for-... ]( https://stackoverflow.com/questions/49854237/is-xxmaxramfraction-1-safe-for-... ) 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
Hi Alex, I have the same dream, and we can get there with ZGC as we make no algorithmic assumptions about the max size of the heap. I have thought about it and have a few ideas how to get there. Currently, adding a young generation is higher up on the priority list though. But this will likely be revisited. Thanks for letting us know that there is demand for such a feature. Thanks, /Erik
On 31 Aug 2021, at 21:37, alex@syncwords.com wrote:
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.:
- [ https://blog.arkey.fr/2020/10/27/maxrampercentage-is-not-what-i-wished-for/ ]( https://blog.arkey.fr/2020/10/27/maxrampercentage-is-not-what-i-wished-for/ ) - [ https://stackoverflow.com/questions/49854237/is-xxmaxramfraction-1-safe-for-... ]( https://stackoverflow.com/questions/49854237/is-xxmaxramfraction-1-safe-for-... )
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
On 9/1/21 7:13 AM, Erik Osterlund wrote:
I have the same dream, and we can get there with ZGC as we make no algorithmic assumptions about the max size of the heap. I have thought about it and have a few ideas how to get there. Currently, adding a young generation is higher up on the priority list though. But this will likely be revisited. Thanks for letting us know that there is demand for such a feature.
A little while ago I was talking to John Rose about GC ergonomics. I wanted a "compress max" option that conflated the long list of settings we advise our customers to use for small memory. We came up with a pretty sweet idea, based on Unix compress. Have a "-z" setting that specifies the amount of work you're prepared to do. So "-z9" means do whatever it takes, no matter how long it takes, to minimize memory, and "-z0" means use as much memory as you want. I mentioned this to a few people, but never managed to get enough enthusiasm. So I'm trying again, because I still think it's a neat idea. 😊 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 9/1/21 11:01 AM, Andrew Haley wrote:
On 9/1/21 7:13 AM, Erik Osterlund wrote:
I have the same dream, and we can get there with ZGC as we make no algorithmic assumptions about the max size of the heap. I have thought about it and have a few ideas how to get there. Currently, adding a young generation is higher up on the priority list though. But this will likely be revisited. Thanks for letting us know that there is demand for such a feature.
A little while ago I was talking to John Rose about GC ergonomics. I wanted a "compress max" option that conflated the long list of settings we advise our customers to use for small memory.
We came up with a pretty sweet idea, based on Unix compress. Have a "-z" setting that specifies the amount of work you're prepared to do. So "-z9" means do whatever it takes, no matter how long it takes, to minimize memory, and "-z0" means use as much memory as you want. I mentioned this to a few people, but never managed to get enough enthusiasm. So I'm trying again, because I still think it's a neat idea. 😊
I think the closest we get at this point is -XX:ShenandoahGCHeuristics=compact :) -- Thanks, -Aleksey
Hi Andrew, That was roughly my idea as well. 😊 /Erik
-----Original Message----- From: zgc-dev <zgc-dev-retn@openjdk.java.net> On Behalf Of Andrew Haley Sent: Wednesday, 1 September 2021 11:02 To: zgc-dev@openjdk.java.net Subject: Re: The Holy Grail: a GC that doesn't need Xmx
On 9/1/21 7:13 AM, Erik Osterlund wrote:
I have the same dream, and we can get there with ZGC as we make no algorithmic assumptions about the max size of the heap. I have thought about it and have a few ideas how to get there. Currently, adding a young generation is higher up on the priority list though. But this will likely be revisited. Thanks for letting us know that there is demand for such a feature.
A little while ago I was talking to John Rose about GC ergonomics. I wanted a "compress max" option that conflated the long list of settings we advise our customers to use for small memory.
We came up with a pretty sweet idea, based on Unix compress. Have a "-z" setting that specifies the amount of work you're prepared to do. So "-z9" means do whatever it takes, no matter how long it takes, to minimize memory, and "-z0" means use as much memory as you want. I mentioned this to a few people, but never managed to get enough enthusiasm. So I'm trying again, because I still think it's a neat idea. 😊
-- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
participants (4)
-
Aleksey Shipilev
-
alex＠syncwords.com
-
Andrew Haley
-
Erik Osterlund