JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 228 contents

Bye Bye CMS. JEP 363 (Remove the Concurrent Mark Sweep (CMS) Garbage Collector) has been applied in the draft Java 14, so there will no longer be the Concurrent Mark Sweep garbage collector available.

Though it was never the default collector, for a decade it's been the collector of choice for applications that needed good pause time handling (eg anything customer facing or latency sensitive). But it was always a massive pain to tune properly, with way too many tuning flags; even getting the tuning right left it fragile, needing re-tuning when the application was upgraded or the throughput pattern changed or increased; and critically it suffered from fragmentation that you desperately needed to avoid or you would get a huge long (many seconds) pause. My own advice for CMS was to do a basic level of tuning, determine the interval between defragmentation GCs, and take instances out of the cluster more frequently one at a time, do an explicit full GC, then put them back into the cluster.

So with CMS gone, what are your options from Java 14 on? Well as I pointed out in my September newsletter you still have 11 other collectors to choose amongst so you're not exactly lost for choice. A good percentage of applications can transfer to G1 and gain similar pause statistics to CMS. But a significant number will see an unacceptable degradation from switching to G1. These should try out the low pause collectors: ZGC, Shenandoah, metronome, gencon+concurrentScavenge, optavgpause. But do note, the lower the pause you need, the higher the memory and additional (non-application) CPU you need to provide.

Now on to this month's tips, tools, news, articles and talks. And of course the tips from this month's articles and talks, as ever are extracted into this month's tips page.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• JFR is available to use for free on Java 8 now, thanks to a backport by OpenJDK
• Remove the Concurrent Mark Sweep (CMS) Garbage Collector has been applied to Java 14 (due for release next March). Say bye bye
• Mission Control development is now officially on GitHub. Say hello
• TornadoVM OpenJDK plug-in let's your app automatically run on multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs

Tools

Java performance tuning related tools.

• TornadoVM OpenJDK plug-in that let's your app automatically run on multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs
• Using machine learning to optimize performance automatically
• Micrometer vendor-neutral instrumentation facade to instrument your JVM-based application
• A Java library for accessing NUMA (Non Uniform Memory Access) API

Articles

• Achieving Low-Latency in the Cloud with OSS (Mark Price/QCon)
• SLOs Are the API for Your Engineering Team (Charity Majors/InfoQ)
• Is writing performant code too expensive? (Tomasz Kowalczewski/GeeCON)
• What do I do with 1000 cores (Andrzej Grzesik/GeeCON)

Jack Shirazi

Back to newsletter 228 contents