JDK-5086514 : CMS: +ExplicitGCInvokesConcurrent can hang when +CMSIncrementalMode
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-08-13
  • Updated: 2008-09-25
  • Resolved: 2006-11-14
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 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-5025281 - Allow System.gc() to trigger concurrent (not stop-the-world) full collections
Description
CMSIncrementalMode currently uses certain young gen allocation
point threshold crossings to act as the strobe to enable and
disable the CMS work. ExplicitGCInvokesConcurrent runs CMS
when asked to full gc. If there's an application where,
for example, all activity is stopped while a single thread
invokes System.gc(), then we have a circular deadlock --
the System.gc() call will (by design) not return
until the old gen collection is completed by the CMS thread.
In turn the CMS thread will not start the collection cycle
unless there is allocation activity in the young gen that
will strobe it.

We need to fix this mal-interaction of the two features.
###@###.### 2005-06-06 16:51:58 GMT
Comments
SUGGESTED FIX Event: putback-to Parent workspace: /net/jano/export/disk05/hotspot/ws/main/gc_baseline (jano:/export/disk05/hotspot/ws/main/gc_baseline) Child workspace: /net/prt-web.sfbay/prt-workspaces/20060918140630.iv159533.gc_baseline.5086514/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20060918140630.iv159533.gc_baseline.5086514/workspace) User: iv159533 Comment: --------------------------------------------------------- Job ID: 20060918140630.iv159533.gc_baseline.5086514 Original workspace: jano:/home/iv159533/gc_baseline.5086514 Submitter: iv159533 Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060918140630.iv159533.gc_baseline.5086514/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060918140630.iv159533.gc_baseline.5086514/workspace/webrevs/webrev-2006.09.18/index.html Fixed 5086514: CMS: +ExplicitGCInvokesConcurrent can hang when +CMSIncrementalMode Bug description: CMSIncrementalMode currently uses certain young gen allocation point threshold crossings to act as the strobe to enable and disable the CMS work. ExplicitGCInvokesConcurrent runs CMS when asked to full gc. If there's an application where, for example, all activity is stopped while a single thread invokes System.gc(), then we have a circular deadlock -- the System.gc() call will (by design) not return until the old gen collection is completed by the CMS thread. In turn the CMS thread will not start the collection cycle unless there is allocation activity in the young gen that will strobe it. Fix outline: The iCMS is disabled in at the start of the appropriate VM operation and enabled back in it's epilogue. Webrev: http://javaweb.sfbay/~iv159533/webrev.5086514 Fix verified (y/n): y Testing: custom test case Reviewed by: Ramki, Andrey Files: update: src/share/vm/gc_implementation/includeDB_gc_shared update: src/share/vm/gc_implementation/shared/vmGCOperations.cpp update: src/share/vm/runtime/concurrentMarkSweepThread.cpp update: src/share/vm/runtime/concurrentMarkSweepThread.hpp Examined files: 3876 Contents Summary: 4 update 3872 no action (unchanged)
26-09-2006
SUGGESTED FIX One possibility is to recognise that the two are enabled together and to relax the incremental nature of the collection when we notice that such an explicit GC call is pending. Another refinement is to relax the incremental nature of the collection as above only when young gen activity has fallen below a certain threshold indicating that the application is likely waiting for the call to complete before taking on further application load (which typically translates to allocation load). ###@###.### 2005-06-06 16:51:58 GMT
06-06-2005
WORK AROUND don't use the two flags together if you are going to be calling System.gc() in a thread while all other threads stop all allocation activity. A workaround is of course to +DisableExplictGC, but then +ExplictGCInvokesConcurrent becomes a no-op too and this whole bug becomes a non-issue. ###@###.### 2005-06-06 16:51:58 GMT
06-06-2005
EVALUATION We'll likely end up deferring this work to Dolphin. Meanwhile, customers please refer to the workaround field to avoid this bug.
09-10-2004