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

[Kelvin Nilsen]

On Mon, 16 Feb 2026 23:58:30 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:
> 
>   Improve comments

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

> 136: }
> 137: 
> 138: void ShenandoahAdaptiveHeuristics::compute_headroom_adjustment(size_t mutator_available) {

No need for mutator_available as an argument and no need to compute byte_allocated_at_start_of_idle.

Comment: if someone changes soft_max_capacity(), this should be called to recompute.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 123:

> 121:   void start_idle_span() override;
> 122: 
> 123:   // If old-generation marking finishes during an idle span and immediate old-generation garbage is identified, we will rebuild

Maybe this is redundant with start_idle_span or not even necessary (since start_idle_span doesn't need bytes_available.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 221:

> 219:   TruncatedSeq _available;
> 220: 
> 221:   ShenandoahFreeSet* _free_set;

Can we use TruncatedSeq::predict_next() for this linear prediction?

Also, can we get rid of _regulator_thread, _control_thread, is_generational?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2819588055
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2819593262
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2819601069