SUGGESTED FIX



http://analemma.sfbay/net/spot/scratch/ysr/cisco/webrev
###@###.### 2005-05-19 21:52:42 GMT

Event:            putback-to
Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
                  (jano.sfbay:/export/disk05/hotspot/ws/main/gc_baseline)
Child workspace:  /net/prt-web.sfbay/prt-workspaces/20050519120549.ysr.cisco/workspace
                  (prt-web:/net/prt-web.sfbay/prt-workspaces/20050519120549.ysr.cisco/workspace)
User:             ysr

Comment:

---------------------------------------------------------

Original workspace:     sr1-unwk-13:/net/spot/scratch/ysr/cisco
Submitter:              ysr
Archived data:          /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050519120549.ysr.cisco/
Webrev:                 http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050519120549.ysr.cisco/workspace/webrevs/webrev-2005.05.19/index.html

Fixed 6250214: CMS: perm gen expansion eithout explicit GC, but with concurrent cycle initiation

The mem_allocate() method of perm gen would force a stop-world
GC when expanding perm space every MaxPermHeapExpansion bytes.
This is a fine policy for the stop-world collectors, but blows
pause times for the CMS collector. We now avoid a full stop-world
GC in the case of CMS unless we have reached the limit and
the allocation has failed.

Existing CMS triggering policy would (as Jon pointed out) then
start a CMS cycle at the next scavenge following the perm gen
expansion. Since one expects allocation rates in the young gen
to be much larger than in perm gen, this synchronous sampling
based policy for initiating CMS collection appears to suffice
for the moment, rather than asynchronously triggering the
CMS cycle upon the perm gen expansion event.

In a separate bug, i'll consider restructuring some of this code
so as to avoid the repeated lock/unlock of the free list lock
in the work loop.

Reviewed by: Jon Masamitsu

Fix Verified: yes

Verification Testing: spec+CMS with
   +DisableExplicitGC PermSize=1M MaxPermHeapExpansion=4K
   and noted that perm gen expands without initiating a
   stop-world GC.
 
Other testing: PRT, refworkload

Files:
update: src/share/vm/memory/permGen.cpp
update: src/share/vm/runtime/concurrentMarkSweepThread.hpp

Examined files: 3268

Contents Summary:
       2   update
    3266   no action (unchanged)
###@###.### 2005-05-19 23:33:07 GMT
                                     

WORK AROUND

-XX:PermSize=<m> -XX:MaxPermSize=<m>
sizes the initial perm gen at the max value and works around the issue.

-XX:MaxPermHeapExpansion=<x> can be used to make the
problem less frequent. The default value of <x> is 4MB;
a larger value will proportionately decrease the frequency
of full gc's for expanding the perm gen.

Users who enable Perm gen collection via
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
might not notice this problem (much) because old gen memory
pressure will collect (and appropriately expand) the perm gen.
###@###.### 2005-04-04 19:28:53 GMT
                                     

EVALUATION

see comments section.
###@###.### 2005-04-04 19:29:43 GMT