3 comments
> selecting something else depending on arcane environmental conditions was more of a burden than an advantage<p>What is being referred to here? Does "else" refer to ZGC, Shenandoah?<p>What does arcane env conditions mean?
It's in the JEP (<a href="https://openjdk.org/jeps/523" rel="nofollow">https://openjdk.org/jeps/523</a>):<p>> 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.
Are people still dealing with GC issues?<p>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.
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.<p>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.
GC'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.