JDK 27 G1/Parallel/Serial GC Changes

Discussion (3 Comments)Read Original on HackerNews

kasperni•39 minutes ago

Are people still dealing with GC issues?

I find that it basically just more or less works out of the box on modern JVMs.

kelseyfrog•3 minutes ago

It's selection bias. There's a huge number of GC language users, but those who experience problems tend to be the ones who comment.

You're right; the vast majority of people use GC just fine and go about their day. We should update little to none when we see evidence of GC hardship.

hylaride•19 minutes ago

There are edge cases where GC issues can crop up, in particular specific "serverless" models (eg AWS lambdas) where the JVM can get "paused" between executions and GC doesn't cleanly run, causing memory to trend upwards until the next cold-start happens (especially if you're running it within a docker container yourself). Limited CPU situations that can exist in these kinds of runtime environments also limit GC in several ways, too.

skullone•8 minutes ago

What's it like running JVM inside serverless? Python gets interesting enough when it pauses waiting for another call sometimes, the JVM seems like it'd introduce its own interesting things :o

smallnix•about 1 hour ago

> selecting something else depending on arcane environmental conditions was more of a burden than an advantage

What is being referred to here? Does "else" refer to ZGC, Shenandoah?

What does arcane env conditions mean?

aatos•34 minutes ago

It's in the JEP (https://openjdk.org/jeps/523):

> We made G1 the default collector for server environments in JDK 9 (JEP 248). At that time, testing showed that Serial had significant advantages in throughput and footprint in constrained environments with a single CPU or less than 1792 MB of physical memory. We therefore adjusted the JVM's GC selection algorithm to choose Serial in such environments.

JDK 27 G1/Parallel/Serial GC Changes

⚡ Community Insights

Discussion (3 Comments)Read Original on HackerNews