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

[Aleksey Shipilev]

On Tue, 17 Nov 2020 17:12:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I did some performance tests on the variant of this patch, and while it regresses throughput in some scenarios, that's the price we pay for additional spike safety. I think we can drop current alloc-spike and penalty tracking (even from `shenandoahHeuristics`?).
>> 
>> Another round of tune-ups follows.
>
>> @shipilev , what workload are you running? I'd like to run it as well.
> 
> SPECjbb2015 and SPECjvm2008, hacked^W adapted for newer JDKs.
> 
>> I'm reluctant to remove the headroom and penalty adjustments. They're an additional layer of safety and let the user provide information about the application that we wouldn't otherwise know. Perhaps we could externalize the penalty adjustments for headroom as command line arguments? If somebody wants to run closer to the edge, they could set the headroom and penalties to zero.
> 
> I think spike threshold already covers both parts. Does HyperAlloc perform worse if you remove both `AllocSpikeFactor` and GC/Degen penalties? If you are unsure, we can leave these as is. But the flipside is that we make heuristics hoard more free memory than it already does.

I think we are nearing the integration. Please merge (don't rebase) from master to get GH actions updates. (In fact, I cannot see "Testing" section in your first comment -- that one is supposed to be added by bots. Do you have GH actions disabled?)

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

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