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

[Paul Hohensee]

On Mon, 15 Sep 2025 23:06:36 GMT, Paul Hohensee <phh at openjdk.org> wrote:

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

If there are two evac closure versions, then the choice must be made at a higher level than at the closure invocation point, otherwise it's the same cost.

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

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