RFR (S) 8213373: Bulk MarkBitMap clearing methods

[Roman Kennke]

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.

Roman

> On 11/05/2018 06:17 PM, Aleksey Shipilev wrote:
>> RFE:
>>   https://bugs.openjdk.java.net/browse/JDK-8213373
>>
>> Fix:
>>   http://cr.openjdk.java.net/~shade/8213373/webrev.00/
>>
>> 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.
> 
> Thanks,
> -Aleksey
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181114/eec848ec/signature.asc>