United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6211366 : CMS: large unused perm gen can degrade scavenge times on MP

Details
Type:
Bug
Submit Date:
2004-12-21
Status:
Resolved
Updated Date:
2010-05-09
Project Name:
JDK
Resolved Date:
2005-03-17
Component:
hotspot
OS:
solaris
Sub-Component:
gc
CPU:
unknown
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_06
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

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
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
                                     
2004-12-21
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
                                     
2004-12-21
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
                                     
2004-12-21



Hardware and Software, Engineered to Work Together