Jonas Norlinder
OpenJDK 26 introduces new telemetry to quantify the CPU-memory trade-off in garbage collection.

Dissecting the CPU-Memory Relationship in Garbage Collection

Every time you configure a Java application's heap size, you are essentially making a trade-off: spending more on infrastructure to improve performance metrics such as throughput or latency. Historically, this trade-off was visible when an undersized heap triggered long pauses, signaling a need for more resources. With modern collectors, however, pause duration and computational effort have become decoupled. This creates an operational blind spot: dashboards may show excellent response times, while the collector silently consumes excess compute capacity to compensate for a constrained heap. To address this, it is essential to look beyond GC pauses and examine overall efficiency using new tools. This article, therefore, analyzes why we need additional metrics for infrastructure efficiency and introduces the new MemoryMXBean.getTotalGcCpuTime() API in Java 26 (OpenJDK 26), which empowers engineers and researchers to quantify the collector's CPU overhead and make informed memory-CPU trade-off decisions.

Escaping the gravity of legacy code. Taking JVM performance to the moon!

One Giant Leap: 95% Less Sampling Cost

Imagine your company is managing a large-scale data processing system, and every second counts. You're constantly seeking ways to reduce latency and optimize performance. Now, consider the impact of speeding up thread monitoring on user CPU time by 20 times. The public standard in Linux for reading thread CPU time is the computational equivalent of printing a spreadsheet to paper, then scanning it with a camera, only to digitize it back into a spreadsheet just to read a value. It works, but it destroys throughput. I recently integrated a patch into OpenJDK that replaces this legacy logic with direct calls. The result is a 20x speedup for thread monitoring of user CPU time. Here is the story behind the optimization and why "everything is a file" isn't the right philosophy for performance.

The views expressed in this blog are my own and do not necessarily reflect the views of Oracle.