Why You Should Tune Code Before Your Garbage Collector

Why You Should Tune Code Before Your Garbage Collector

I tested how redundant logging impacts latency compared to choosing different Java Garbage Collectors like ZGC and Shenandoah. My benchmarks reveal that optimizing code to remove unnecessary work often matters far more than tuning the Garbage Collector, sometimes even flipping which collector performs best for your specific workload.

Optimising your memory allocations in Java could make far more difference than your choice of Garbage Collector and may even change which is the best garbage collector.
  1. hinkley

    It's like caching, in kind but not in type. Once you add it, people will stop trying to be parsimonious with resources and just reach for the cache every time. They'll just lean into it. In a hot minute you will discover you can't turn it off because people have lost their brains and the data flow of the app is through the cache and not through the call tree.

    If you tune for allocation patterns that are in the code, then you are cementing those as continuing in perpetuity. Better to cut the fat first, so that you can tune for the necessary complexity instead of the accidental. That will be self-correcting because any new misuses will be taxed with higher performance regressions.

  2. peter_lawrey

    In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector

  3. peterabbitcook

    Reading this gives me considerable pause - I can’t think of many classes within the codebase I work on that don’t have @Slf4j at the top…

    Since there wasn’t a link to the source code in that post, can you help me understand this - for the SLF4J baseline is your logger impl a console appender, a file appender, or a network service like an OTel collector? Does any of that matter for GC context?

  4. syngrog66

    I stopped reading early when it became clear the author didn't understand the terms (or perhaps the entire language) they were using. Several indicia.

  5. einpoklum

    Garbage collector?

    To quote Bjarne Stroustrup:

    > I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible.

More from this day

2026-07-13