JDK 27 G1/Parallel/Serial GC Changes
tschatzl.github.io
JDK 27 G1/Parallel/Serial GC Changes
1–10 of 36 posts
Re: JDK 27 G1/Parallel/Serial GC Changes
#2> 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?
Re: JDK 27 G1/Parallel/Serial GC Changes
#3Are people still dealing with GC issues?
I find that it basically just more or less works out of the box on modern JVMs.
Re: JDK 27 G1/Parallel/Serial GC Changes
#4> 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?
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.
Re: JDK 27 G1/Parallel/Serial GC Changes
#5Are people still dealing with GC issues? I find that it basically just more or less works out of the box on modern JVMs.
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.
Re: JDK 27 G1/Parallel/Serial GC Changes
#6GC's haven't freed us from manual memory management, you just do all that manual work with environment variables, or making sure to "pick the right collector for the job", or debugging performance or heap size issues, or chasing down weak references or confused finalizers.
Re: JDK 27 G1/Parallel/Serial GC Changes
#7Are people still dealing with GC issues? I find that it basically just more or less works out of the box on modern JVMs.
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 se…
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
Re: JDK 27 G1/Parallel/Serial GC Changes
#8Are people still dealing with GC issues? I find that it basically just more or less works out of the box on modern JVMs.
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.
Re: JDK 27 G1/Parallel/Serial GC Changes
#9Earlier quoted context omitted.
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 se…
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
Other than some GC issues, meaning we had to give it more memory than we'd otherwise like thereby making them a bit more expensive, it's mostly been fine. The key to ephemeral java is keeping scope limited and not using it when cold starts matter (which can cause a bit of jitter in execution lag). Our use case was asynchronous, so it worked.
We wanted to investigate using the native AWS java lambdas with snapstart and/or using parallel GC, but the place I used them at a year ago was under the tyranny of product having complete control of our backlog, so we didn't get to go that far with it or even more serious tech debt for that matter.
More memory may or may not even be much of an issue depending on your workload. If you can handle the odd OOM error it would have been fine, but for our use case lambdas were so cheap that it didn't really matter, outside of us techies preferring to do it "right". Having the max execution time be less than 15m could also minimize the heap bloat at the cost of more cold starts.
Re: JDK 27 G1/Parallel/Serial GC Changes
#10Are people still dealing with GC issues? I find that it basically just more or less works out of the box on modern JVMs.
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.
It depends a lot on the scale of the system, which often means that those fewer users are actually doing things that are more complex and more valuable - either at the lower end or at the high end.