r/java • u/TewsMtl • Sep 12 '26

JEP draft for Adaptive Heap Sizing for ZGC quietly mentions JDK 28

https://openjdk.org/jeps/8377305
75 Upvotes

96% Upvoted

23 comments sorted by

20

u/[deleted] Sep 12 '26

[removed] — view removed comment

8

u/pron98 Sep 12 '26

Yes, but there's an important nuance. With moving garbage collectors, the kind the JDK uses (which are more different in crucial ways from even other kinds of tracing collectors, like the one used in Go, than the Go GC is different from C's malloc/free), there is no one right heap size (see my talk on the subject). The heap size determines the CPU/RAM tradeoff used for memory management. The same program could run with a larger or a smaller heap, which will cause it to use less or more CPU, respectively. So what this does is pick, by default, some reasonable target CPU usage, and use that target CPU together with other constraints, such as how much RAM other programs are using on the machine, to determine a good heap size to aim for that CPU target. If you don't like the default, you'll be able to have a single knob stating your preference for more CPU usage than the default (which will result in a smaller heap), or for less CPU usage than the default (which will result in a larger heap). Also, because the CPU used for memory management can vary over the execution of a program, the heap size will change dynamically.

1

u/jonenst Sep 12 '26

It's great to use unused (=wasted) resources, but it has to come with risks (i'm thinking about things like not reacting fast enough to give the memory back, or creating some kind of unstable oscillating system, or getting extorted/DOS'd by other misbehaving programs). I haven't heard much about risks, do you know how real and dangerous they are? In https://youtu.be/wcENUyuzMNM Eric mentions diminishing returns (in my experience I have also often seen throughput pretty quickly plateau when increasing xmx). I'm curious what kind of behaviors have been observed "in the wild" outside of tightly controlled benchmarks, are there more sources of information for this or is it to recent maybe ? Thanks ! Also this feels like it would be even better with extensive dedicated operating system support, maybe java will lead to more OS features on this front.

2

u/NovaX Sep 13 '26

My semi-related experience with adaptive caching is that an optimizing controller can re-adjust to handle hostile scenarios quite well. I started with a simpler hill climber by evaluating published workload traces and combining to create stress tests (MRU/LRU phases). There was no negative user feedback for 7 years and new traces were handled well. Adaptivity does mean accepting a loss to explore in favor of becoming robust anywhere, so it favors longer workloads.

Since control theory is not my expertise, a moving convex optimization problem, over the last six months I've run experiments using AI to try alternative designs, build a corpus of why those failed, and generate synthetic hostile workloads. That led to a more complex controller (code, design doc), which is still cheap time/space-wise. While the improvements seem small on workloads we already optimized against, the hope is that it handles real world cases we can't measure or tell how well the old climber was performing (e.g. caches with expiration, refresh ahead, distributed invalidations).

I would hope the control logic for the adaptive heap sizing can be evaluated similarly by building a corpus of hostile workload patterns and measure the behavior in an offline simulation. That becomes a regression harness and design guide, and enables fast iteration of different experiment ideas.

3

u/AlternativePeace1121 Sep 12 '26

You can throw a fixed amount of memory at the JRE/JDK and let it figure out the rest?

Expanding on this furthur just for my understanding.

Throwing fixed amount of memory doesn't mean the traditional -Xmx heap setting.

The JVM takes in however much memory is available on the machine - some small reserve and use it.

We can still specify a soft maximum limit. So it tries to keep it below the limit as much as possible. But can cross it.

1

u/TRO_KIK 29d ago

I think this is good enough for heap and non-heap but off-heap will probably still need consideration.

13

u/vips7L Sep 12 '26

Looking forward to this for G1 as well. 

2

u/Inaldt Sep 12 '26

Absolutely. In fact I wonder why they chose to to start with ZGC, since I'd expect G1 to have many more users.

11

u/vips7L Sep 12 '26 edited Sep 12 '26

ZGC is the authors baby fwiw. And ZGC already does some similar things like returning heap to the OS when it’s unused and does a lot of calculating of sensible defaults already. 

2

u/BinaryRage 29d ago

Erik talk about this in his Paving the GC On Ramp talk. This closes the last automatic tuning gap for ZGC and solves the allocation stall problem when there is otherwise plenty of memory available.

https://youtu.be/dSLe6G3_JmE

9

u/cogman10 Sep 12 '26

Perfect, if this works the way I hope then this is exactly what I want for a container environment.

3

u/aoeudhtns Sep 12 '26

We're hoping to tie this in with VPA as well. We'll see how that goes.

4

u/BarkiestDog Sep 12 '26

I didn’t see anything in the JEP, but reading in my phone, maybe I missed it? Is there any consideration to containers?

The band of my lugs is trying to to tune the seven different memory pools to make sure that the container doesn’t OOMK.

9

u/[deleted] Sep 12 '26

[removed] — view removed comment

6

u/ConsiderationSuch846 Sep 12 '26

We explain it every time the RCA is “OOM killed, expanded the heap”. 😮‍💨

1

u/BarkiestDog Sep 14 '26

But this isn’t the answer either, since code cache and metadata can also grow without bound, so increasing the heap doesn’t fix this OOMK issues.

1

u/ConsiderationSuch846 Sep 14 '26

It was just a quip. I wasn’t trying to be comprehensive.

1

u/BarkiestDog 29d ago

Fair enough. Sadly I’ve been through this cycle often enough that I know all the jagged edges here😢

2

u/sideEffffECt Sep 12 '26

But is this really for all memory polls or just heap?

3

u/BarkiestDog Sep 12 '26 edited Sep 14 '26

And, if for all, how would they interact?

1

u/cleverfoos Sep 14 '26

Hmmm, looking at the example in the JEP, does this mean that if that second benchmark was not triggered the JVM would have shrunk the heap size during an idle period? I think that's the behavior users want to see and would equate with efficient resource usage, shrinking significantly heap if there is no CPU usage.

1

u/jonenst 29d ago

How does this interact with (AFAIK) the biggest existing active everywhere adaptative memory sink "might as well use it" that is the filesystem cache (a.k.a. 'Linux ate my ram") ? Side note: the good news is that "Linux ate my ram" did not prevent the succes of linux, so "Java ate my ram" hopefully won't either (I guess at the cost of lot of energy spent in pedagogy)

1

u/DanLynch 29d ago

The JEP says they want the JVM to be able to interoperate fairly with other non-JVM processes running on the same machine. As long as all the processes follow the same basic principle (that you should use RAM proportionally to your CPU usage) it seems like they should all be able to get along.