RFR (S) 8213373: Bulk MarkBitMap clearing methods
rkennke at redhat.com
Wed Nov 14 12:03:38 UTC 2018
The change looks good & useful. Thanks!
Makes me wonder if the decision large or not could be made in
MarkBitMap, i.e. if range exceeds a certain threshold, switch to large
clearing, otherwise do small. ? Doesn't seem very important though.
> On 11/05/2018 06:17 PM, Aleksey Shipilev wrote:
>> We have found this a while ago in Shenandoah: there is an easy improvement for older compilers,
>> non-optimized builds, unusual build modes. This micro-optimization is sometimes very fruitful, and
>> it makes us less reliant on smart compilers. It depends on JDK-8211926 fixed first.
> JDK-8211926 is in.
>> The impact of this is difficult to measure with G1, but here are historical figures from Shenandoah
>> here: http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-January/001564.html
>> I put the _large calls in G1 where it seems to fit: where we clear the bitmaps in bulk, e.g. from
>> bottom to end of the heap region. Shenandoah does it on all paths, including from bottom to top,
>> without apparent loss.
>> Testing: hotspot tier1
> This passed jdk-submit as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev