RFR(S): 8040807: G1: Enable G1CollectedHeap::stop()

Per Liden per.liden at oracle.com
Tue May 27 11:15:07 UTC 2014


I did some additional testing and eyeballing of this fix and noticed 
that it would be a good idea to also tell concurrent mark to abort, 
otherwise we will always wait until concurrent mark has finished, which 
is unnecessary (and could potentially take some time if the live set is 
large). So, I added a call to _cm->set_has_aborted() to abort any 
ongoing concurrent mark.

Updated webrev:

Diff against previous webrev:

Wrote a simple test to provoke an concurrent mark followed by an 
immediate exit. With the first version of the patch, we would always 
wait until concurrent mark completes. Now it will instead show an 
concurrent-mark-abort, which happens much earlier.


On 05/22/2014 03:10 PM, Per Liden wrote:
> Thanks Jon!
> /Per
> On 2014-05-20 16:45, Jon Masamitsu wrote:
>> Looks good.
>> Reviewed.
>> Jon
>> On 05/20/2014 04:59 AM, Per Liden wrote:
>>> Looking for a couple of reviews in this patch.
>>> Summary: This patch re-enables the controlled stopping of G1's
>>> concurrent threads at VM shutdown. This could potentially cause hangs
>>> during VM shutdown because the G1 marking threads could get stuck in
>>> various places and fail to terminate. JDK-8040803 and JDK-8040804
>>> fixed these issues, so this is the final step to re-enable the actual
>>> stopping of those threads. This patch also moves the call to
>>> CollectedHeap::stop() a few lines down to group the GC related stuff
>>> together. It also adjusts/removes some comments that are no longer
>>> correct.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040807
>>> Webrev: http://cr.openjdk.java.net/~pliden/8040807/webrev.0/
>>> Testing:
>>> - GC nightlies. 5 tests in this suite used to timeout because of the
>>> issue with hanging threads. They now pass.
>>> - JPRT
>>> Thanks!
>>> /Per

More information about the hotspot-gc-dev mailing list