RFR(S): 8040807: G1: Enable G1CollectedHeap::stop()
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.
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!
> On 2014-05-20 16:45, Jon Masamitsu wrote:
>> Looks good.
>> 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
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040807
>>> Webrev: http://cr.openjdk.java.net/~pliden/8040807/webrev.0/
>>> - GC nightlies. 5 tests in this suite used to timeout because of the
>>> issue with hanging threads. They now pass.
>>> - JPRT
More information about the hotspot-gc-dev