RFR(s): 8044796: G1: Enabled G1CollectedHeap::stop()
per.liden at oracle.com
Fri Jun 13 11:32:39 UTC 2014
On 06/13/2014 12:34 PM, Stefan Johansson wrote:
> 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.
> On 2014-06-12 12:09, Per Liden wrote:
>> 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
>> 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().
More information about the hotspot-gc-dev