JDK-7051430 : CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs22
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-03
  • Updated: 2011-11-25
  • Resolved: 2011-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u2Fixed 8Fixed hs22Fixed
Description
This is especially painful in debug mode when the cycles run slower and longer
on account of extra checking done. absent abrupt tremination of an ongoing cycle,
we add significantly to each run, and increase the nightly testing duration
significantly for no benefit at all. Thus getting this fixed quickly will
help with testing and analysis for the organization as a whole. See also related
CR 6220168.
Comments
EVALUATION See main CR
12-09-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ef2d1b8f2dd4
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ef2d1b8f2dd4
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ef2d1b8f2dd4
13-06-2011
SUGGESTED FIX diff --git a/src/share/vm/runtime/java.cpp b/src/share/vm/runtime/java.cpp --- a/src/share/vm/runtime/java.cpp +++ b/src/share/vm/runtime/java.cpp @@ -468,12 +468,9 @@ StatSampler::disengage(); StatSampler::destroy(); -#ifndef SERIALGC - // stop CMS threads - if (UseConcMarkSweepGC) { - ConcurrentMarkSweepThread::stop(); - } -#endif // SERIALGC + // We do not need to explicitly stop concurrent GC threads because the + // JVM will be taken down at a safepoint when such threads are inactive; + // see destroy_vm(). // Print GC/heap related information. if (PrintGCDetails) { diff --git a/src/share/vm/runtime/thread.cpp b/src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp +++ b/src/share/vm/runtime/thread.cpp @@ -3698,6 +3698,9 @@ // heap is unparseable if they are caught. Grab the Heap_lock // to prevent this. The GC vm_operations will not be able to // queue until after the vm thread is dead. + // After this point, we'll never emerge out of the safepoint before + // the VM exits, so concurrent GC threads do not need to be explicitly + // stopped; they remain inactive until the process exits. MutexLocker ml(Heap_lock); VMThread::wait_for_vm_thread_exit();
10-06-2011
EVALUATION Yes; see comments for the latest.
08-06-2011