RFR: Adaptive CSet selection selects excessively when memory is tight
Roman Kennke
rkennke at redhat.com
Mon Jun 11 10:55:43 UTC 2018
Am 11.06.2018 um 12:39 schrieb Aleksey Shipilev:
> http://cr.openjdk.java.net/~shade/shenandoah/adaptive-cset-garbage/webrev.01/
>
> There is a trouble in adaptive cset selection that causes it to grossly overshoot cset when memory
> is tight. When that happens, and we need to clean up enough memory to match free threshold, we would
> have we have the "min memory to free" guidance, and there we should count *garbage* that would be
> reclaimed, not the live cset.
>
> Example where it fails: say we have 100G heap, we need to free 10G, and there are 1000 regions that
> are 10% live. Each region is then 100M, has 10M live data, current LDS is 10G. Current adaptive cset
> selection would erroneously choose 10G / 10M = 1000 regions for the collection set, evacuating all
> these 10G, the entire LDS (*argh*)! While we need only 10G / 90M = 111 regions to reclaim those 10G,
> evacuating only ~1G of live data.
>
> Testing: tier3_gc_shenandoah, specjbb
>
Uh-oh. This sounds very reasonable. Please push!
Thanks,
Roman
More information about the shenandoah-dev
mailing list