EXPEDIA GROUP TECHNOLOGY — SOFTWARE

Practical JVM GC tuning for everyone

The modern garbage collection tuning procedure for JVMs

Jack Shirazi
Feb 20, 2020 · 3 min read

At the recent java2days conference, I presented my latest talk “Practical Garbage Collection Tuning For Anyone” which included a detailed decision chart for tuning your JVM’s garbage collection (GC). This is a new way of thinking about GC tuning and makes it amenable for the majority of applications, developers, and operations people.

Update from October 2020 — the recording of the talk is now available at https://www.youtube.com/watch?v=Vs8LOtmtbrg

people holding trash cans: young person — young generation collector; twins — parallel collector; an old man — old generation
people holding trash cans: young person — young generation collector; twins — parallel collector; an old man — old generation

It’s only in the last couple of years that it has become possible to have a simple decision flow you can follow for JVM GC tuning. For most of the last decade GC tuning was arcane and fragile, but now the options are clearer and more targeted and there is a clear step-by-step procedure you can follow which I’ve detailed. The images here show the main outline, in my talk I went into detail on each step of the chart.

The talk was put together from a set of internal micro-lessons we’ve developed within Expedia Group™ to assist our teams in understanding and optimizing JVM garbage collection, possibly at some future date we can publish those. Meanwhile, here’s the decision chart as it currently stands.

Garbage collection tuning flow chart
Garbage collection tuning flow chart
Garbage collection latency tuning flow chart
Garbage collection latency tuning flow chart

The flow shows which GC to choose depending on why your SLO is failing. Follow the flow to find which collector is right for your use case. For example, suppose you go through the steps of the top line of the first slide and find that in your tests or in production your GC latency is too high — a very common scenario. Suppose your targets are that pauses up to 100ms are acceptable, but you can’t really allocate much more CPU or memory (the path through the crossed out green circle). The good news is that the flow chart shows this is achievable without code tuning (bottom rows of the second slide). And it also shows you which collectors you can usefully try: five possible collectors, or four if your app is 24/7 with no interruptions (as in that case it will not be able to manage fragmentation).

The different flow paths show the available options to achieve your targets in a clear step-by-step procedure, and indicate when you might have to switch to code-level tuning (covered in my talk, but no slide yet — hopefully I’ll add one when I give an updated version of this talk at London Devoxx this coming May!).

Learn more about technology at Expedia Group

Expedia Group Technology

Stories from the Expedia Group Technology teams