JDK-6250214 : CMS: perm gen expansion without explicit GC, but with concurrent cycle initiation.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-04-04
  • Updated: 2010-04-02
  • Resolved: 2005-06-03
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.
Other JDK 6
1.4.2_10Fixed 6 b39Fixed
Description
See comments section.
###@###.### 2005-04-04 19:09:59 GMT
Comments
EVALUATION see comments section. ###@###.### 2005-04-04 19:29:43 GMT
04-04-2005
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
04-04-2005
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
04-04-2005