JDK-6407949 : CMS: revisit and retune default settings of Eden, Survivor Spaces etc.
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 Availabitlity Release.
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
Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
Child workspace: /net/prt-web.sfbay/prt-workspaces/20060616171045.ysr.defaults/workspace
Job ID: 20060616171045.ysr.defaults
Original workspace: karachi:/net/spot/scratch/ysr/defaults
Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060616171045.ysr.defaults/
Fixed 6407949: CMS: revisit and retune default settings of Eden, Survivor Spaces etc.
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.
Examined files: 3849
3846 no action (unchanged)
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