RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option

[Paul Hohensee]

On Sun, 14 Sep 2025 01:28:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.

On typical hardware, if the test is in the fast path, the load of ShenandoahEvacTracking will hit in L1, the latency will be absorbed by speculation, and the cmp/branch is a single clock. So maybe 2 clocks at most. Downside is that if ShenandoahEvacTracking is the only thing being accessed in its cache line, you waste an L1 line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2350295732