RFR (M): 8048084: Need to abort concurrent next bitmap clear when marking is aborted during concurrent next bitmap clearing
thomas.schatzl at oracle.com
Mon Jul 7 14:03:52 UTC 2014
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
> 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
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