jonasn

6 ms·

1. 1.▲
   by jonasn 7mo ago

   Thanks for the detailed read and the great questions! Regarding the colors and thread counts in Figure 4: the key piece of context here is that the application thread (the Main thread) is completely paused during this phase. It isn't a
2. 2.▲
   by jonasn 7mo ago

   That is a creative idea, but unfortunately, Epsilon changes the execution profile too much to act as a clean baseline for barrier costs. One huge issue is spatial locality. Epsilon never reclaims, whereas other GCs reclaim and reuse memory
3. 3.▲
   by jonasn 7mo ago

   That is spot on. Effectively disabling GC to establish a baseline is exactly the methodology used in the Blackburn & Hosking paper [1] I referenced. In general, for a production JVM like HotSpot, the implicit cost comes largely from the
4. 4.▲
   by jonasn 7mo ago

   Thanks! It is not currently exposed in JFR for JDK 26, but I agree that it would be the logical next step. Now that the underlying telemetry framework (cpuTimeUsage.hpp) is in place within HotSpot, wiring it up to JFR events would be a natu
5. 5.▲
   by jonasn 7mo ago

   Thanks! I really appreciate that. I spent a lot of time trying to nail the illustrations so I'm really glad it landed well. :-)
6. 6.▲
   by jonasn 7mo ago

   Every GC algorithm in HotSpot is designed with a specific set of trade-offs in mind. ZGC and G1 are fantastic engineering achievements for applications that require low latency and high responsiveness. However, if you are running a pure bat
7. 7.▲
   by jonasn 7mo ago

   Great question! I actually just touched on this in another thread that went up right around the same time you asked this. It is clearly the next big frontier! The short answer is: It's something I'm actively thinking about, but in
8. 8.▲
   by jonasn 7mo ago

   Thanks for reading! Your current method, pushing the load until the GC spirals and then comparing the CPU utilization, is exactly the painful, trial-and-error approach I'm hoping this new API helps alleviate. You've hit on the exa
9. 9.▲
   by jonasn 7mo ago

   Hi HN, I'm the author of this post and a JVM engineer working on OpenJDK. I've spent the last few years researching GC for my PhD and realized that the ecosystem lacked standard tools to quantify GC CPU overhead—especially with mo
10. 10.▲
    Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)(norlinder.nu)

    119 points by jonasn 7mo ago|37 comments
11. 11.▲
    by jonasn 8mo ago

    Thanks for the kind words and the link :).
12. 12.▲
    by jonasn 8mo ago

    You are spot on that the original author had a valid reason: at the time, it was literally the only way to do it. The method in question (Java 1.5) was released in September 2004. While the POSIX standard existed, it only provided a way to
13. 13.▲
    by jonasn 8mo ago

    Author of the OpenJDK patch here. Thanks for the write-up Jaromir :) For those interested, I explored memory overhead when reading /proc—including eBPF profiling and the history behind the poorly documented user-space ABI. Full details