This technical blog post analyzing garbage collection performance in Java does not directly address human rights. However, it demonstrates observable alignment with UDHR principles through its structural choices: free, accessible publication of technical knowledge without paywalls or registration barriers (Article 19), accessible design with alt text (Article 2), and public contribution to scientific advancement (Articles 26-27). The content operates neutrally on human rights dimensions but practices values of open access and knowledge democratization.
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 modern concurrent collectors where pause times don't tell the whole story.
To fix this blind spot, I built a new telemetry framework into OpenJDK 26. This post walks through the CPU-memory trade-off and shows how to use the new API to measure exactly what your GC is costing you.
I'll be around and am happy to answer any questions about the post or the implementation!
At my work, one thing that I've often had to explain to devs is that the Parallel collector (and even the serial collector) are not bad just because they are old or simple. They aren't always the right tool, but for us who do a lot of batch data processing, it's the best collector around for that data pipeline.
Devs keep on trying to sneak in G1GC or ZGC because they hyper focus on pause time as being the only metric of value. Hopefully this new log:cpu will give us a better tool for doing GC time and computational costs. And for me, will make for a better way to argue that "it's ok that the parallel collector had a 10s pause in a 2 hour run".
Thank you for this interface! It will definitely help in tracking down GC related performance issues or in selecting optimal settings.
One thing that I still struggle with, is to see how much penalty our application threads suffer from other work, say GC. In the blog you mention that GC is not only impacting by cpu doing work like traversing and moving (old/live) objects but also the cost of thread pauses and other barriers.
How can we detect these? Is there a way we can share the data in some way like with OpenTelemetry?
Currently I do it by running a load on an application and retaining its memory resources until the point where it CPU skyrockets because of the strongly increasing GC cycles and then comparing the cpu utilisation and ratio between cpu used/work.
Edit: it would be interesting to have the GC time spent added to a span. Even though that time is shared across multiple units of work, at least you can use it as a datapoint that the work was (significantly?) delayed by the GC occurring, or waiting for the required memory to be freed.
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 instrumenting micro-level events (like ZGC's load barriers or G1's write barriers) directly inside application threads without destroying throughput (or creating observer effects invalidating the measurements) is incredibly difficult.
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 batch data pipeline where pause times simply don't matter, Parallel GC remains an incredibly powerful tool and probably the one I would pick for that scenario. By accepting the pauses, you get the benefit of zero concurrent overhead, dedicating 100% of the CPU to your application threads while they are running.
Editorial Channel
What the content says
+0.10
Article 19Freedom of Expression
Medium Practice
Editorial
+0.10
SETL
0.00
Content shares technical knowledge and research freely without gatekeeping, supporting freedom of information expression.
FW Ratio: 50%
Observable Facts
Article is published as free-to-read blog post with no paywall or subscription requirement.
Content includes detailed technical explanation with references and visual diagrams accessible to any reader.
Inferences
Free access removes barriers to knowledge sharing, supporting freedom to impart information and ideas.
Open publication structure enables broader technical discourse without artificial restrictions.
ND
PreamblePreamble
null
Content does not engage with UDHR preamble themes of human dignity, freedom, or justice.
ND
Article 1Freedom, Equality, Brotherhood
null
Content addresses technical equality (equal treatment of CPU and memory costs) but not human equality or dignity.
ND
Article 2Non-Discrimination
High Practice
Not engaged.
FW Ratio: 67%
Observable Facts
Page includes alt text for images: 'OpenJDK 26 introduces new telemetry to quantify the CPU-memory trade-off in garbage collection.'