RFR: 8255984: Shenandoah: "adaptive" heuristic is prone to missing load spikes [v2]
earthling-amzn
github.com+71722661+earthling-amzn at openjdk.java.net
Fri Nov 13 19:01:58 UTC 2020
On Fri, 13 Nov 2020 17:11:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Remove const qualifier from should_start_gc
>>
>> This lets the heuristics update state without const_casts.
>> - Rename ShenandoahReactive flags to ShenandoahAdaptive flags.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 293:
>
>> 291: double instantaneous_rate = _allocation_rate.instantaneous_rate(bytes_allocated_since_gc_start);
>> 292: if (_allocation_rate.is_spiking(instantaneous_rate) && average_cycle_seconds > allocation_headroom / instantaneous_rate) {
>> 293: log_info(gc)("Trigger: Instantaneous allocation rate (%.0f %sB/s) will deplete free headroom (" SIZE_FORMAT "%s) before average time (%.2f ms) to complete GC cycle.",
>
> If you compare the message with previous trigger, you'll probably notice has the different order of printed values: gc time, allocation rate, head room. This one should have the same order. You can change the previous trigger to read:
>
> log_info(gc)("Trigger: Average GC time (%.2f ms) is above the time for average allocation rate (%.0f %sB/s) to deplete free headroom (" SIZE_FORMAT "%s) (margin of error = %.2f)"
>
> ...and this one to read:
>
> log_info(gc)("Trigger: Average GC time (%.2f ms) is above the time for instantaneous allocation rate (%.0f %sB/s) to deplete free headroom (" SIZE_FORMAT "%s) (margin of error = %.2f)",
Done.
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 223:
>
>> 221: if (is_allocation_rate_too_high(capacity, available, bytes_allocated_since_gc_start)) {
>> 222: return true;
>> 223: }
>
> Does this split really win us anything readability-wise? I inlined the methods back, and the method is still quite readable, and does not require tracking `return`-s and pushing local variables there. I wonder if that is just a left-over from adaptive/reactive split.
The change was certainly originally motivated by having these changes in a separate heuristic. I don't think it hurts readability, but I'll inline them back in for the sake of performance.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1099
More information about the shenandoah-dev
mailing list