RFR (M): 8048084: Need to abort concurrent next bitmap clear when marking is aborted during concurrent next bitmap clearing

Thomas Schatzl thomas.schatzl at oracle.com
Mon Jul 7 13:53:43 UTC 2014

Hi all,

  can I have reviews for the following change that is a pre-requisite
for JDK-8038423: G1: Decommit memory within the heap?

The change addresses a problem when concurrent next bitmap clearing is
interrupted by Full GC, we need to abort concurrent next bitmap clear.

On the one hand, the concurrent marking thread might still be working on
a just uncommitted region as next bitmap mark is chunked (so with
JDK-8038423, which leads to instant crashes), and on the other hand this
is superfluous work because the Full GC already did that during mark
abort handling.

There are other workarounds for this issue that could somehow consider
whether the given region they are working on has been uncommitted in the
However I think this adds unnecessary logic into the code. Full GC
already clears the next mark bitmap completely anyway, so why continue
at this point.



JPRT, lots of aurora ad-hoc testing with memory uncommit changes


More information about the hotspot-gc-dev mailing list