RFR: 8364081: Shenandoah & GenShen logging improvement [v2]

[Y. Srinivas Ramakrishna]

On Fri, 25 Jul 2025 15:55:10 GMT, Rui Li <duke at openjdk.org> wrote:

>> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
>> 
>> Also added some generational information for generational shenandoah logging.
>> 
>> Shenandoah logging samples:
>> 
>> 
>> ######################
>> Shenandoah - Beore GC
>> ######################
>> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
>> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
>> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.161s][debug][gc,heap      ] GC(0) 
>> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
>> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> ######################
>> Shenandoah - After GC
>> ######################
>> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
>> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
>> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
>> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
>> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
>> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
>> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
>> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
>> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
>> [2.179s][debug][gc,heap        ] GC(9) 
>> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
>> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
>> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, commit...
>
> Rui Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8364081: Shenandoah & GenShen logging improvement

I am wondering if we could just hoist the incrementing of the collections count to `run_gc_cycle()` which would normally take care of everything at once in one place, with the option `true` for stw and full cases.

It would probably miss the upgrade to full at a degen. We could either overcount by incrementing at the point of upgrade to full or gloss over it. I'd do the former (which is what I believe your degen upgrade to full does here).

(The other, perhaps arguably (or subjectively) better semantics, for full in the case of concurrent collectors is to conflate degens with full, treating both as a kind of failure of concurrent mode.

The problem is that the "total collections & full collections" terminology is inadequate when we have concurrent gcs, both young & old, global (explicit system.gc() invoking a concurrent gobal), and concurrent mode failures (degens) of each kind of collection. So I am guessing at some point we'll need to expand this semantics smoothly to accommodate these other kinds of collection.

However, this can be done later as an RFE that smoothly integrates what JFR et al. do as well.)

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 582:

> 580: 
> 581: void ShenandoahHeap::print_heap_on(outputStream* st) const {
> 582:   bool is_generational = mode()->is_generational();

`const`

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 602:

> 600:     st->print_cr(" %zu x " PROPERFMT " regions",
> 601:                 num_regions(),
> 602:                 PROPERFMTARGS(ShenandoahHeapRegion::region_size_bytes()));

I'd print this info for GenShen above as well.

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

PR Review: https://git.openjdk.org/jdk/pull/26469#pullrequestreview-3056812581
PR Review Comment: https://git.openjdk.org/jdk/pull/26469#discussion_r2232023228
PR Review Comment: https://git.openjdk.org/jdk/pull/26469#discussion_r2232053574