RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3]

[William Kemper]

On Mon, 5 Jan 2026 20:39:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements:
>> 
>> 1. Track trends in GC times rather than always using the average GC time plus standard deviation.  In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory.
>> 2. Sample allocation rates more frequently than once every 100 ms.
>> 3. Track trends in allocation rates.  In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload.
>> 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove develop/debug instrumentation

Took another look over this. There is a lot to get through. I'll have more later.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 179:

> 177:                " after adjusting for spike_headroom: %zu%s"
> 178:                " and penalties: %zu%s", _is_generational? _space_info->name(): "Global",
> 179:                byte_size_in_proper_unit(mutator_available),   proper_unit_for_byte_size(mutator_available),

Can we use the `PROPERFMT/PROPERFMTARGS` macros for these? I find they really improve readability.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 199:

> 197: 
> 198: // There is no headroom during evacuation and update refs.  This information is not used to trigger the next GC.
> 199: // Rather, it is made available to support throttling of allocations during GC.

Is that true? or is allocation throttling part of another change?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 275:

> 273: }
> 274: 
> 275: void ShenandoahAdaptiveHeuristics::add_gc_time(double timestamp, double gc_time) {

Could we use `TruncatedSeq::predict_next` here?

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1218:

> 1216:   } else {
> 1217:     heap->heuristics()->start_idle_span();
> 1218:   }

Suggestion:

  _generation->heuristics()->start_idle_span();

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29039#pullrequestreview-3632535527
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666483213
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666485239
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666489076
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666310682