days
-6
-1
hours
0
-1
minutes
-4
-8
seconds
-1
-8
search
Just the algorithm, not the GCs themselves

JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination

Chris Stewart
JEP 366
© Shutterstock / AnnaTamila

We’ve seen a lot of talk about different garbage collectors lately; JEPs 364 and 365 want to port the Z Garbage Collector to macOS and Windows respectively, JEP 363 wants to remove the deprecated Concurrent Mark Sweep (CMS) garbage collector. And now we have JEP 366, which is proposed to target JDK 14 and wants to deprecate the combination of the Parallel Scavenge and Serial Old garbage collection algorithms. Let’s take a closer look.

In development projects, we all know (or should do) how important it is not to spend too much effort for too little benefit somewhere along the way. And if we do spot that happening, then it’s important to do something about it. The diligent team working on the future of Java has come to this conclusion about the seemingly rare combination of ParallelScavenge and SerialOld garbage collectors. And so, JEP 366 was born.

This is not a default combination, meaning it has to have been activated manually by the user in the command line. The author of JEP 366, Thomas Schatzl, writes:

This combination is unusual since it pairs the parallel young generation and serial old generation GC algorithms. We think this combination is only useful for deployments with a very large young generation and a very small old generation. In this scenario the full collection pause times might be bearable due to the small size of the old generation. In practice this is a very rare and risky deployment, since a slight shift in liveness for objects in the young generation will result in an OutOfMemoryException, since the old generation is significantly smaller than the young generation. The only advantage of this combination compared to using a parallel GC algorithm for both the young and old generations is slightly lower total memory usage. We believe that this small memory footprint advantage (at most ~3% of the Java heap size) is not enough to outweigh the costs of maintaining this GC combination.

    In a cloud native world enamored with microservices and serverless, meet Quarkus – Java’s brilliant response to technologies like Node.js, Python and Go that had proven quicker, smaller and arguably more nimble. Download your free beginner's tutorial written by JAX London speaker Alex Soto.

Non-goals, risks & assumptions

Schatzl is very careful to point out that it is not a goal to remove the garbage collector combination, just to deprecate it, and that this is the only combination under consideration for deprecation.

He also states they can only assume that this GC combination is, in fact, a highly uncommon one, and that if it turns out there is a significant number of users they will have to reconsider the proposed deprecation.

JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination

The specifics of the proposal are as follows:

  • Deprecate the option combination -XX:+UseParallelGC -XX:-UseParallelOldGC
  • Deprecate the option -XX:UseParallelOldGC

SEE ALSO: JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector

The latter deprecation is because it was only used to deselect the parallel old generation garbage collector, enabling the serial old generation garbage collector. Because of these deprecations, using UseParallelOldGC will trigger a deprecation warning, as will using -XX:+UseParallelOldGC on its own to select the parallel young and old generation garbage collection algorithms. The only way to opt for parallel young and old generation garbage collection algorithms without triggering a warning will be to specify -XX:+UseParallelGC on the command line.

Finally, Schatzl writes the following:

The only change is the deprecation message; there is no loss of functionality. The existing collector called “Parallel”, which combines the parallel young generation and parallel old generation algorithms, has almost the same behavior and should be a drop-in replacement.

SEE ALSO: JEP 365: ZGC on Windows

That’s it for JEP 366. At the time of writing it is proposed to target JDK 14, and we will find out on Friday what the community thinks of that, so keep an eye out for our Java 14 update news; we update that regularly so you know what’s going on with Java 14.

In the meantime, why not check out JEP 366 in all its glory here.

Author
Chris Stewart
Chris Stewart is an Online Editor for JAXenter.com. He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of