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

Aleksey Shipilev shade at openjdk.java.net
Tue Nov 17 17:15:05 UTC 2020

On Mon, 16 Nov 2020 08:39:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> earthling-amzn has updated the pull request incrementally with six additional commits since the last revision:
>>  - Inline calls to gc decision methods (vestige of an earlier design)
>>  - Use os::elapsedTime to avoid type issues and to be consistent with other heuristics code
>>  - Reuse instantaneous_rate method instead of duplicating code
>>  - Rename variables to improve readability
>>  - Make logging messages more consistent
>>  - Restore call to reset allocation counter at cycle start
> 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.


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

More information about the hotspot-gc-dev mailing list