RFR(s): 8044796: G1: Enabled G1CollectedHeap::stop()
Stefan Johansson
stefan.johansson at oracle.com
Fri Jun 13 10:34:50 UTC 2014
Hi Per,
The change looks good. Hopefully there are no more rare corner cases to
trip over and if there are I think it's good to get the change in to
find them.
StefanJ
On 2014-06-12 12:09, Per Liden wrote:
> Hi,
>
> Here's another (hopefully last) attempt at fixing issue with stopping
> G1's concurrent threads at VM shutdown.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044796
> Webrev: http://cr.openjdk.java.net/~pliden/8044796/webrev.0/
>
> The previous attempt tried to abort any ongoing concurrent mark to
> speed up the shutdown phase. This turned out to be a bad idea as it
> opened up another race, which could result in threads getting stuck
> again. So, this time I just wait for concurrent mark to complete
> before terminating. We've talked internally here about some
> alternatives to force an abort, but it seems all alternatives
> complicates the code way too much and introduces new states which is
> hard to verify and it just isn't worth it.
>
> What worries me a bit is that the problems potentially introduced by a
> change like this are very hard to detect as they tend to be race
> conditions and show up only now and then. The previous fix had gone
> through a fair bit of testing without showing any problems. This new
> fix has gone thought 5 iterations of GC nightlies (Aurora adhoc
> submissions), 3 iterations of gc-test-suite and passed all JTReg G1
> tests.
>
> About the fix. Since I no longer try to abort concurrent work the
> stop() function became just a call to stop_conc_gc_threads(). Since
> stop_conc_gc_threads() isn't used anywhere else I simply moved its
> contents to stop() and removed stop_conc_gc_threads().
>
> Thanks!
> /Per
More information about the hotspot-gc-dev
mailing list