RFR (S) 8213373: Bulk MarkBitMap clearing methods

Aleksey Shipilev shade at redhat.com
Mon Nov 5 17:17:22 UTC 2018



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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181105/743d9d43/signature.asc>

More information about the hotspot-gc-dev mailing list