RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4]
Kelvin Nilsen
kdnilsen at openjdk.org
Thu Jan 15 18:43:01 UTC 2026
On Fri, 9 Jan 2026 22:20:51 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
>>
>> - Fix comment
>> - Use PROPERFMT macros
>> - Simplify code flow: reviewer suggestion
>> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers
>> - Remove develop/debug instrumentation
>> - add another override
>> - Change type of command-line args
>> - fix white space
>> - Add override to virtual methods
>> - Fix race between allocation reporting and querying
>> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 643:
>
>> 641: future_accelerated_planned_gc_time * 1000);
>> 642: } else {
>> 643: log_trigger("Momentary spike consumption (%zu%s) exceeds free headroom (%zu%s) at "
>
> Should the 'Momentary spike' trigger replace the 'instantaneous spike' trigger? It seems like we now have two spike detecting triggers?
We could maybe. The conditions under which each triggers are slightly different. I have seen situations where the new Momentary spike consumption triggers when the old "instantaneous spike" did not trigger. Potentially, the other could also happen, though I have not observed it, where the old "instantaneous spike" triggers but momentary spike does not. (Momentary spike is evaluated every 15 ms, whereas instantaneous spike is evaluated every 100 ms. At the time we evaluate a momentary spike, there might be an abundance of runway so we do not trigger. A less extreme instantaneous spike might be observed at a later time, when runway is less plentiful, and that would trigger.
Out of an abundance of caution (belts and suspenders), I was thinking to keep both triggers in place.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695536563
More information about the shenandoah-dev
mailing list