RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV
Mikael Gerdin
mikael.gerdin at oracle.com
Thu Apr 3 13:59:02 UTC 2014
Hi Per,
On Thursday 03 April 2014 13.15.12 Per Liden wrote:
> Hi,
>
> Could I please have this bugfix reviewed.
>
> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
> the JVM is about to exit and the gclog_or_tty instance has been
> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
> SuspendibleThreadSet before accessing gclog_or_tty.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
While I realize that this code is still semantically correct I think it reads
a bit strange. In my mind if we have a
if (...) {} else if (...) {} else {} block the checks in the "if" and "else
if" should usually somehow related checks.
282 if (!cm()->has_aborted()) {
283 g1_policy->record_concurrent_mark_cleanup_completed();
284 } else if (G1Log::fine()) {
285 gclog_or_tty->date_stamp(PrintGCDateStamps);
286 gclog_or_tty->stamp(PrintGCTimeStamps);
287 gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
288 }
I would prefer if it was structured the other way around:
if (cm()->has_aborted()) {
if (G1Log::fine()) { ... }
else {
g1_policy->record_concurrent_mark_cleanup_completed();
}
The rest of the change looks good.
/Mikael
>
> Thanks!
> /Per
>
> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
> cleanup of the SuspendibleThreadSet and how it's used. Will send that
> out as separate review request shortly.
More information about the hotspot-gc-dev
mailing list