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 00:24:58 UTC 2020
On Wed, 11 Nov 2020 08:15:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Thanks for updates. I would like to dive in with some testing. Second read nits below, meanwhile.
>
> Oh, and change PR title to "8255984: Shenandoah: "adaptive" heuristic is prone to missing load spikes", so that bots know what issue it refers to.
Though we tested this with several benchmarks and internal services, these changes were primarily developed using the [HyperAlloc](https://github.com/corretto/heapothesys/tree/master/HyperAlloc) benchmark. The attached chart shows stacked histograms for the heuristics that triggered a collection cycle during a run of HyperAlloc.
Each test run was given a 3g heap. HyperAlloc targeted a 1g/s allocation rate (-a 1000) with a max object size of 1000 bytes (-x 1000). It was configured to maintain 1gb of live objects on the heap (-s 1024) and it ran for two minutes (-d 120). Each row in the chart is for a different _allocation smoothness factor_. The top row has an allocation smoothness of zero (i.e., most spiky), the bottom row has an allocation smoothness of 0.4, still spiky, but manageable. Each column in the chart is a different heuristic. On the left is the original `adaptive` heuristic (with default parameters). On the far right is the `compact` heuristic. In the middle are runs of the original `reactive` heuristic with different sensitivities to allocations spikes. The purple bars are allocation failures. The light blue bars are instances where an allocation spike was detected and triggered a cycle.

-------------
PR: https://git.openjdk.java.net/jdk/pull/1099
More information about the shenandoah-dev
mailing list