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)
                                     

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
                                     

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
                                     

EVALUATION

We'll likely end up deferring this work to Dolphin.
Meanwhile, customers please refer to the workaround field to avoid this bug.