JDK-6250214 : CMS: perm gen expansion without explicit GC, but with concurrent cycle initiation.
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.
See comments section.
###@###.### 2005-04-04 19:09:59 GMT
see comments section.
###@###.### 2005-04-04 19:29:43 GMT
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
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
###@###.### 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