United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7051430 CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit
7051430 : CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit

Details
Type:
Bug
Submit Date:
2011-06-03
Status:
Closed
Updated Date:
2011-11-25
Project Name:
JDK
Resolved Date:
2011-09-30
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs22

Related Reports
Backport:
Backport:

Sub Tasks

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
                                     
2011-09-12
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ef2d1b8f2dd4
                                     
2011-07-08
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ef2d1b8f2dd4
                                     
2011-07-08
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ef2d1b8f2dd4
                                     
2011-06-13
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();
                                     
2011-06-10
EVALUATION

Yes; see comments for the latest.
                                     
2011-06-08



Hardware and Software, Engineered to Work Together