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.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list