RFR: Adaptive/Traversal heuristics rewrite for allocation rate

Roman Kennke rkennke at redhat.com
Wed Aug 22 10:48:09 UTC 2018


The patch looks good.

- Have you looked at it in visualizer? Does it look reasonable?
- Have you actually tried with high-LDS workloads (ideally in visualizer)?

Thanks,
Roman

> http://cr.openjdk.java.net/~shade/shenandoah/alloc-rate-heuristics/webrev.02/
> 
> Our current free-threshold based heuristics are good when heap is not over-occupied. When the heap
> is over-occupied, it has a few positive feedback loops that make it runaway into back-to-back
> cycles, never recovering even if heap occupancy goes down. It can be observed by free threshold
> latching to one aggressive value and never going down. My attempts at resolving that in a simple
> manner were not successful.
> 
> To add insult to injury, free-threshold is also indirect: it targets the free space with assuming
> things about allocation rate, the GC time needed to collect it, etc. It all works well when workload
> is very steady-state and not otherwise.
> 
> This rewrite makes the adaptive/traversal heuristics track the allocation rate and gc times, and
> schedule the next GC when it knows allocations would deplete the free space while GC is running. It
> also adjusts the "headroom" available based on the max CSet cap, has the reserve for absorbing
> allocation spikes, and has negative feedback loop from degen/full GCs.
> 
> It does not regress our current benchmarks, but does not improve them either -- because, as said
> above, current heuristics works well until it runs away. It should work much more reliably on
> non-steady-state workloads.
> 
> Testing: tier3_gc_shenandoah, specjbb, specjvm
> 
> Thanks,
> -Aleksey
> 



More information about the shenandoah-dev mailing list