JDK-6634032 : CMS: Need CMSInitiatingPermOccupancyFraction for perm, divorcing from CMSInitiatingOccupancyFraction
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u15,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-11-26
  • Updated: 2010-04-02
  • Resolved: 2008-05-21
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.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs13Fixed
Related Reports
Relates :  
Description
The current CMS (static) triggering strategy is:

   if ((old gen occupacy % > CMSInitiatingOccupancyFraction) ||
       (perm gen is subject to concurrent collection &&
        (perm gen occupancy % > CMSInitiatingOccupancyFraction)) then
    ... start a CMS collection

By conflating old gen threshold with perm gen threshold, one might unnecessarily
do CMS collections when there is lots of free space in the old gen but relatively
little space in the perm gen. For 32-bit JVM's where address space is limited,
one may not have the luxury of a large MaxPermSize just to work around this
limitation.

Accordingaly, we want to refine the above strategy to something along the
lines of:

   bool collect_old = old gen occupancy % > CMSInitiatingOccupancyFraction;
   bool collect_perm =  (perm gen is subject to concurrent collection &&
                         (perm gen occupacny % > CMSInitiatingPermOccuapncyFracton));
   if (collect_perm) {
     ... start a CMS collection, certainly including perm gen
   } else if (collect_old) {
     ... start a CMS collection, possibly excluding perm gen
   }

Comments
WORK AROUND If possible use a larger perm size so as to keep perm gen occupancy always below the initiating fraction. But this may not always be feasible. especially in a 32-bit JVM.
12-06-2008

SUGGESTED FIX repo: /net/jano2/export2/hotspot/hg/hotspot-gc.clean changeset: 15:0834225a7916 user: ysr date: Sun Mar 16 21:57:25 2008 -0700 description: 6634032: CMS: Need CMSInitiatingPermOccupancyFraction for perm, divorcing from CMSInitiatingOccupancyFraction Summary: The option CMSInitiatingPermOccupancyFraction now controls perm triggering threshold. Even though the actual value of the threshold has not yet been changed, so there is no change in policy, we now have the infrastructure in place for dynamically deciding when to collect the perm gen, an issue that will be addressed in the near future. Reviewed-by: jmasa files: src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp src/share/vm/runtime/globals.hpp
17-03-2008

SUGGESTED FIX JPRT: 2008-03-17-160112.ysr.gc-clean
08-12-2007

EVALUATION Yes.
26-11-2007