Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

norlinder.nu

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#11

Post by firefly2000 »

jonasn wrote: post #7
firefly2000 wrote: post #5

Are there plans to elucidate implicit GC costs as well?

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…

Do you think it can be done by adjusting GC aggressiveness (or even disabling it for short periods of time) and correlating it with execution time?

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#12

Post by mattclarkdotnet »

Sorry if this is obvious to Java experts, but much as parallel GC is fine for batch workloads, is there a case for explicit GC control for web workloads? For example a single request to a web server will create a bunch of objects, but then when it completes 200ms later they can all be destroyed, so why even run GC during the request thread execution?

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#13

Post by jacobn »

mattclarkdotnet wrote: post #12

Sorry if this is obvious to Java experts, but much as parallel GC is fine for batch workloads, is there a case for explicit GC control for web workloads? For example a single request to a web server will create a bunch of objects, but then when it completes 200ms later they can all be destroyed, so why even run GC during the request thread execution?

Most web request cases where you care about performance probably have multiple parallel web requests, so there’s no clean separation possible?

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#14

Post by latchkey »

jonasn wrote: post #2

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 tra…

I built this 15 years ago and it got fairly popular, but is long dead now...

https://github.com/jmxtrans/jmxtrans

Kind of amazing how people are still building telemetry into Java. Great post and great work. Keep it up.

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#15

Post by yunnpp »

jacobn wrote: post #13
mattclarkdotnet wrote: post #12

Sorry if this is obvious to Java experts, but much as parallel GC is fine for batch workloads, is there a case for explicit GC control for web workloads? For example a single request to a web server will create a bunch of objects, but then when it completes 200ms later they can all be destroyed, so why even run GC during the request thread execution?

Most web request cases where you care about performance probably have multiple parallel web requests, so there’s no clean separation possible?

His question is still valid for latency. That parallel GC in Java still seems to pause threads from a quick search. https://inside.java/2022/08/01/sip062/

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#16

Post by exabrial »

jonasn wrote: post #2

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 tra…

I just want to say this is an incredibly detailed, well written, and beautifully illustrated article. Solid work.

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#17

Post by yunnpp »

jonasn wrote: post #2

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 tra…

Hey, noob question, but does OpenJDK look at variable scope and avoid allocating on the heap to begin with if a variable is known to not escape the function's stack frame?

Not strictly related to this post, but I figured it'd be helpful to get an authoritative answer from you on this.

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#18

Post by sitta »

jonasn wrote: post #2

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 tra…

Great article!

Will the new metric be exposed in JFR recordings as well?

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#19

Post by mattclarkdotnet »

jacobn wrote: post #13
mattclarkdotnet wrote: post #12

Sorry if this is obvious to Java experts, but much as parallel GC is fine for batch workloads, is there a case for explicit GC control for web workloads? For example a single request to a web server will create a bunch of objects, but then when it completes 200ms later they can all be destroyed, so why even run GC during the request thread execution?

Most web request cases where you care about performance probably have multiple parallel web requests, so there’s no clean separation possible?

Sure, but each request has its own context. Shared resources like DB connection pools will be longer lived but by definition they aren’t alllcated by the request thread. So why not simply exempt everything allocated by a request thread from GC, and simply destroy it on request completion?

Re: Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)

#20

Post by pgrulich »

yunnpp wrote: post #17
jonasn wrote: post #2

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 tra…

Hey, noob question, but does OpenJDK look at variable scope and avoid allocating on the heap to begin with if a variable is known to not escape the function's stack frame? Not strictly related to this post, but I figured it'd be helpful to get an authoritative answer from you on this.

Yes, Hotspot performs Escape Analysis to avoid heap allocation. This is a nice article: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...
Post reply on HN