JDK-6407949 : CMS: revisit and retune default settings of Eden, Survivor Spaces etc.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-04-03
  • Updated: 2010-04-02
  • Resolved: 2006-06-28
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
6 b90Fixed
Related Reports
Relates :  
JDK-6465357 - CMS: default choice of NewSize can cause obscure startup failure w/small -Xms
Relates :  
JDK-6427025 - CMS: NewRatio ignored in the setting of NewSize and MaxNewSize
Description
With some recent work on scalability of CMS remark,
and availability of newer hardware, it makes sense
to retune some CMS defaults for better out-of-the-box
performance.
Comments
SUGGESTED FIX 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/20060616171045.ysr.defaults/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20060616171045.ysr.defaults/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20060616171045.ysr.defaults Original workspace: karachi:/net/spot/scratch/ysr/defaults Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060616171045.ysr.defaults/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060616171045.ysr.defaults/workspace/webrevs/webrev-2006.06.16/index.html Fixed 6407949: CMS: revisit and retune default settings of Eden, Survivor Spaces etc. Webrev: http://analemma.sfbay/net/spot/scratch/ysr/defaults/webrev It has been apparent for a while that the current default settings of CMS, especially its policy of "promote all survivors" was suboptimal for typical configurations where it would place excessive pressure on the old gen allocation as well as collection, in some cases leading to avoidable concurrent mode failure and/or an excessively fragmented heap. At the same time, the march of progress means that machines come with more memory than was the case when these defaults were chosen, memory is slightly faster and CPU's are much faster. (Of course, low pause applications are also more demanding and stringent in their requirements but we'll assume that in those cases most users will tune their heaps much more carefully in those cases and ignore that particular demographic for the purposes of setting defaults.) It has also become abundantly clear from recent usage feedback and experience that CMS is used much more in large heap server settings than in small heap client settings. Indeed, for small heaps it is expected that stop world serial or parallel gc might be competitive for a while yet, especially considering the footprint and start-up penalties measured sometime ago with CMS. This putback revises the defaults so as to use a larger young generation as well as enabling the use of survivor spaces. The values used were determined based on a slew of runs in the vicinity of the old and new values and choosing an optimal number that did not trade off much in pause times while improving throughput. The result is that for server benchmarks there's an across the board reduction in GC overheads and concommitant improvement in application throughput and scores. For the client benchmarks there is the expected increase in footprint even though there's the expected reduction in GC time overheads. GC pauses increase only by a few percent whereas GC overheads decline several-fold. This thus appears to be a good server-centric OOB performance tradeoff. While testing this code, I tweaked the triggering threshold computation so as to account for the fact that the computation normally obtains at the end of a scavenge. This causes slightly earlier triggering than before and avoids some "close to the edge" concurrent mode failures because of starting the just-in-time collection a wee-bit too late. During that exercise I found the data in PrintCMSInitiationStatics useful, so converted it to a product flag to allow use in product builds; the overhead is negligible even when enabled. Note that the use of survivor spaces regresses the CMS initial checkpoint/mark pause times by a factor that brings them close to the cms remark times. This is being addressed in CR 6412968 for Mustang RC. Also included is a CMSUseOldDefaults flag (set to false) that will, if switched on, revert to the old CMS defaults for these tunables. Reviewed by: J. Masamitsu, T. Printezis, A. Petrusenko Approved by: Mustang Core Team (Azar Nohadani) Fix Verified: yes Verification Testing: (performance) . refworkloads, client and server with CMS and iCMS; see bug report for summary data and pointers to logs. Other testing: . PRT Files: update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/runtime/arguments.cpp update: src/share/vm/runtime/globals.hpp Examined files: 3849 Contents Summary: 3 update 3846 no action (unchanged)
20-06-2006
EVALUATION We might opportunistically try and get this in for Mustang if testing is clean and there are no performance regressions. However, this is nominally targeted to Dolphin for process reasons.
04-04-2006