JFR Event for live set size in ZGC
Erik Osterlund
erik.osterlund at oracle.com
Fri Jan 13 15:35:14 UTC 2023
Hi Jaroslav,
Exposing the liveness number that we already have in ZGC gc logs in a JFR event sounds pretty straight forward and not controversial to me. It’s worth mentioning though that generational ZGC is around the corner, so might be good to make sure it fits in there as well. While liveness information will still be logged in generational ZGC, it is tracked per generation collection, and there is a one-to-many relationship between GC cycles and generation collections.
We have defined the model such that there are minor vs major GCs. A minor collection always collects the young generation only, while a major collection collects the young generation (at least once but sometimes twice) and the old generation. The young collections will log liveness for the young generation, and the old collections will log liveness for the old generation. So we don’t get liveness of the entire system in that sense. But having said that, exposing in events the liveness info we log seems not controversial to me.
With that said, I agree this sounds like useful information and don’t mind if you want to tinker with it. You can check out the generational ZGC code here: https://github.com/openjdk/zgc/tree/zgc_generational
Erik Duveblad is currently tinkering a little bit with the JFR code for generational ZGC, and sent an email to jmc-dev about what we would like to do there.
/Erik
On 12 Jan 2023, at 16:56, Jaroslav Bachorík <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>> wrote:
Hello,
I am trying to resurrect my PR (https://github.com/openjdk/jdk/pull/2579) about adding a JFR event for live set size but in a less ambitious form.
Having this information in a JFR recording would be extremely useful for Datadog but I am sure that other perf tools vendors might be interested in this as well.
Instead of trying to add this event to all GC implementations I would like to circle back and add this event to a single implementation at a time, given that adding such an event would not be controversial or negatively affect the GC implementation by doing significantly more work just in order to compute the live set size.
I would like to start with ZGC where the live set size is already known and quite easy to use without any additional computation.
From my previous work on this problem it seems like adding this event for Shenandoah, ParallelGC and Epsilon should also not create a lot of controversy.
I am looking for feedback before investing more time in this effort - I would really like to avoid the situation I experienced with my previous PR when it was basically shot down after quite a lot of time spent on developing and reviewing it.
Cheers,
-JB-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20230113/0bf981a9/attachment-0001.htm>
More information about the hotspot-gc-dev
mailing list