RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option
Kelvin Nilsen
kdnilsen at openjdk.org
Sun Sep 14 01:32:28 UTC 2025
On Thu, 11 Sep 2025 23:31:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326:
>
>> 324: return ShenandoahBarrierSet::resolve_forwarded(p);
>> 325: }
>> 326:
>
> Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check. I'm curious to see if there is a measurable impact on performance from this change.
If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures. One calls the templated version try_evacuate_object() that has this instrumentation in it. The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it. For LRB, I assume we could have an if-then-else to decide which version to call. LRB evacuations are quite rare, I believe, so that doesn't bother me so much.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2347058185
More information about the hotspot-gc-dev
mailing list