RFR: 8255984: Shenandoah: "adaptive" heuristic is prone to missing load spikes [v4]

Aleksey Shipilev shade at openjdk.java.net
Mon Nov 16 19:41:08 UTC 2020


On Thu, 12 Nov 2020 22:23:27 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 212:
>> 
>>> 210:   ShenandoahAdaptiveHeuristics *heuristic = const_cast<ShenandoahAdaptiveHeuristics *>(this);
>>> 211:   heuristic->_allocation_rate.sample(bytes_allocated_since_gc_start);
>>> 212:   heuristic->_last_trigger = OTHER;
>> 
>> Shouldn't `_last_trigger` updates be near `return true;` in this method? I.e. we should not probably overwrite `_last_trigger` if nothing was actually triggered? This probably affects the super-call to `ShenandoahHeuristics::should_start_gc()` as well?
>
> Would it make more sense if I `OTHER` were `NONE`? The intention here is to only adjust the allocation rate or spike detection parameters if they triggered the cycle. Here we reset the `_last_trigger` in one place without having to touch all the actual decision points. As it stands, once a gc cycle is started, the control thread won't call back into this method until the cycle is complete.

(realized I have not replied here) `OTHER` is fine. `NONE` implies no trigger at all, which is a lie when some trigger actually acts :)

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

PR: https://git.openjdk.java.net/jdk/pull/1099



More information about the hotspot-gc-dev mailing list