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 14:03:52 UTC 2014

Hi all,

On Mon, 2014-07-07 at 15:53 +0200, Thomas Schatzl wrote:
> 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
> meantime.
> 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.
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8048084/webrev/
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8048084
> Testing:
> JPRT, lots of aurora ad-hoc testing with memory uncommit changes

Please hold off reviewing this change for now as testing showed a
problem right now.

Sorry for the trouble.


More information about the hotspot-gc-dev mailing list