February 25, 2026
Pauses lie, CPUs cry
Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)
Java adds a 'CPU tax meter' and devs feud over old-school vs new-school cleanup
TLDR: OpenJDK 26 adds telemetry to show how much CPU garbage collection really costs, even when apps look fast. The community is split: veterans defend older collectors, others want manual control for web requests, and many ask for deeper metrics on hidden overhead—because wasted compute means wasted money.
Java’s getting a new dial in OpenJDK 26: a way to see how much CPU the garbage collector is secretly burning while your dashboard says everything’s fine. The author, Jonas Norlinder, dropped in to say he built new telemetry so teams can finally measure this “CPU tax” and stop guessing. Cue the drama. One camp cheered the honesty—“your fast responses might be hiding a compute fire”—while skeptics warned that automatic cleanup has always fooled developers into ignoring messy code. As one put it, memory bloat is pain, not magic.
Then the brawl broke into factions. The old-school brigade flexed: batch jobs love the classic, simpler collectors—think trusty pickup truck over fancy self-driving car. One veteran fumed that devs keep “sneaking in” modern collectors because they’re hypnotized by short pauses, even if throughput tanks. The tinkerers chimed in with a spicy question: what if web servers just didn’t clean up mid-request—can we push the broom after the page loads? Meanwhile, the scientists asked for the sequel: great, you measured visible CPU, but when do we get metrics for the hidden costs—those little code hooks that slow things down in the shadows? In short: OpenJDK 26 brings a new truth meter, and the crowd is split between “finally,” “told you so,” and “let me drive the trash truck myself.”
Key Points
- •Modern concurrent collectors decouple pause duration from computational effort, making pauses an unreliable efficiency metric.
- •OpenJDK 26 adds telemetry and a Java API to quantify GC-specific CPU overhead for better memory–CPU trade-off decisions.
- •The article defines a GC cost taxonomy: explicit GC cost, implicit GC cost (barriers), and microarchitectural effects.
- •Measuring implicit GC costs is difficult; prior research (Blackburn and Hosking, 2004) used Jikes RVM to establish barrier-free baselines.
- •Traditional reliance on pause times as a proxy for machine load has weakened, necessitating new efficiency metrics and tools.