JDK-6211366 : CMS: large unused perm gen can degrade scavenge times on MP
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2_06
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: unknown
  • Submitted: 2004-12-21
  • Updated: 2010-05-09
  • Resolved: 2005-03-17
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_08Fixed 6 b28Fixed
Description
Customer found that when PermSize and MaxPermSize were made
large, even though most of this space was not actually
used, scavenge times went up dramatically when using the
ParNew+CMS collectors. The problem was not present when
DefNew+CMS was used, nor was it present with just ParNew.
###@###.### 2004-12-21 18:55:15 GMT
Comments
WORK AROUND For applications that have a large dynamic range of occupancy of the perm gen there appears to be no real workaround. For applications that do not have a large dynamic range in the perm gen, a solution is to keep as little free space (head room) above the perm gen as possible. This will avoid card-scanning/chunking penalties associated with the large unused linear allocation block. ###@###.### 2004-12-21 18:55:15 GMT
21-12-2004
EVALUATION The problem was identified as the pessimistic setting of _unallocated_block which was subsequently used for determining the range of the card table to be scanned for the perm gen. With DefNew, _unallocated_block is not used by default. Nevertheless, even with +BlockOffsetArrayUseUnallocatedBlock, it was found that DefNew did not suffer a large penalty from scanning a mostly empty (unused) perm gen. The parallel scanning code appears to suffer a large penalty as in the Noviforum test case, which should be independently investigated. For the case of Posco, in the short term, though, it appears to suffice to use a more discriminating definition of used_region() which exploits the fact that perm gen may be using all of the unused perm space as a single large linear allocation block. For a set of diffs that takes the above approach, see the suggested fix section. ###@###.### 2004-12-21 18:55:15 GMT For a simpler, cleaner fix from Jon, see suggested fix section. ###@###.### 2004-12-21 19:46:54 GMT
21-12-2004
SUGGESTED FIX see http://analemma.sfbay/net/spot/scratch/ysr/bugs/webrev.posco for a preliminary webrev wrt the Mustang (1.6) train. This may be used as a starting point for the fix, and is easily portable in its current form back to the 1.4.2 release train. ###@###.### 2004-12-21 18:55:15 GMT Jon M. suggested the following cleaner, simpler fix, being the deletion of a single line from the CFL space c'tor: This is the change in compactibleFreeListSpace.cpp 79 #if 0 // Investigating large parnew pauses for large perm gen 80 _bt.alloc_block(addr, addr + fc->size()); 81 #endif ###@###.### 2004-12-21 19:46:54 GMT
21-12-2004