JFR Event for live set size in ZGC

[Kemper, William]

We also thought it would be nice to know liveness information without need for concern over which generation was being collected or whether or not the heap was walked during a safepoint. We created a prototype that walks the entire heap, concurrently - but without barriers.


This has some advantages:

  *   Independence from any particular collector implementation or operation[1].
  *   Low overhead, allows memory profiling without lengthy safepoint operations.

Also, some disadvantages:

  *   Walking the object graph concurrently, without barriers reduces the accuracy (but not by much in our testing).
  *   It must abandon any work in progress when a collector runs.
  *   It does add some overhead as it is walking the heap, but it did not affect benchmark scores (specjbb2015).


The code began as an internal "Hackathon" project and was further extended by an intern last summer. We are not using it in production and it needs more testing. That being said, it does work (on Linux, on x86_64) and it seems relevant to the topic so we wanted to share this. I've created a draft PR to facilitate the discussion: https://github.com/openjdk/jdk/pull/12002


[1] There is some explicit integration work to support ZGC because the heap walker needs to decode the color bits. If there is a better/generic interface for this, please let me know.


Thank you,

William

[https://opengraph.githubassets.com/b1d3b787d5459d906c155dc46eedecf116f001a4441f74debe5a390f6cc8c49b/openjdk/jdk/pull/12002]<https://github.com/openjdk/jdk/pull/12002>

Concurrent liveness estimation by earthling-amzn · Pull Request #12002 · openjdk/jdk · GitHub<https://github.com/openjdk/jdk/pull/12002>
github.com
These changes introduce a component that provides an estimation of the number, size and distribution of objects in the heap. It does this independently of any collector implementation or operation. It walks the heap concurrently, without any barriers. For this reason, it provides only an estimation (our testing has shown the estimation is generally accurate).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20230113/b85b3fee/attachment.htm>