###@###.### 2005-05-19 21:52:42 GMT
Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
Child workspace: /net/prt-web.sfbay/prt-workspaces/20050519120549.ysr.cisco/workspace
Original workspace: sr1-unwk-13:/net/spot/scratch/ysr/cisco
Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050519120549.ysr.cisco/
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
Other testing: PRT, refworkload
Examined files: 3268
3266 no action (unchanged)
###@###.### 2005-05-19 23:33:07 GMT