JDK-6887571 : Increase default heap config sizes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs16,6u18
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2009-10-01
  • Updated: 2019-04-11
  • Resolved: 2011-03-08
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
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
JDK-7012344 - Massive memory/process size increases in recent java releases
Relates :  
JDK-6999606 - runtime/threads/CancellableThreadTest fails with OutOfMemoryError on JDK7 b118 fastdebug bits
Relates :  
JDK-6896099 - Integrate CMS heap ergo with default heap sizing ergo
Relates :  
JDK-6898160 - Need serviceability support for new vm argument type 'uint64_t'
Relates :  
JDK-8222252 - Java ergonomics limits heap to 128GB with disabled compressed oops
Description
The default client vm heap config since 2000 has been the equilvalent of

-Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15

for sparc32, and

-Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15

for x86.  OldSize and NewSize are the initial committed sizes of the old
and young gens respectively.  A full gc is required to increase the committed
size of the old gen.

At the time, 64m was half of the 128m of memory typically available on high-end
desktops, many client applications were satisfied with small heaps (hence the
low -Xms value), and gc times were such that the young gen had to be fairly small
in order to minimize pause times.

Since that time, low end desktops and laptops, as well as netbooks and smartbooks,
typically come with 256m, client applications have become much more "server-like",
and we've realized that small young gen sizes increase the frequency of young gcs
and the amount of transient data promoted to the old gen to levels that noticeably
impact startup and steady-state performance, principally by provoking full gcs.
We also note that young gen collection times are proportional to the total survivor
size rather than young gen size and that small (in absolute terms) survivor spaces
for promotion of transient objects.

This CR proposes that we change the default heap config to

-Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15

I.e., leave SurvivorRatio and MaxTenuringThreshold alone, but increase absolute
survivor space sizes significantly.  We still want as many objects to die in the
young gen as possible, so MaxTenuringThreshold reamins at maximum.  NewRatio is
set to the server default of 2.
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/0799687b7385
13-11-2009
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/0799687b7385
29-10-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/473cce303f13
29-10-2009
SUGGESTED FIX Extend server class heap sizing to the client with a few changes. Server heap sizing ergonomics should be unaffected. 1. NewRatio is set to 2 for all platforms to accomodate an increase in transient data size. 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every platform except 64-bit x86 (where it was 6) in any case, so it isn't a big change. 3. MaxTenuringThreshold is left at 15 (the maximum). 4. Add MaxRAM, whose implemented definition matches the current comment for DefaultMaxRAM in globals.hpp. MaxRAM is the maximum physical memory size used to compute MaxHeapSize rather than the maximum possible value of MaxHeapSize set by ergonomics. Replace DefaultMaxRAM with ErgoHeapSizeLimit for the latter purpose. Add support for a new argument type, uint64_t, and used it as the type of MaxRAM. uintx doesn't have the necessary range on 32-bit systems: a user might want to specify 4g for MaxRAM on a 32-bit system. One result of this change is that when using the 32-bit vm on 64-bit systems with more than 4gb of physical memory, the initial committed size of the heap is smaller than it would be under the old ergo. The old ergo used as the initial committed size min(physical-memory/64, maxheapsize). The new ergo uses min(min(physical-memory, MaxRAM)/64, MaxHeapSize)). This is a feature because it avoids overcommitment of memory in cases where the vm is short-lived or doesn't turn out to actually require the memory. 5. The other Default* switches have been stripped of the "Default" prefix, since to their values are just as much "default" values as the values of any of other vm switch, and those don't have a "Default" prefix. DefaultMaxRAMFraction is left as a synonym for MaxRAMFraction for the moment because QA uses it. When they change to MaxRAMFraction, DefaultMaxRAMFraction will be removed. 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() and is used for everything except CMS. CMS has it's own, incompatible, heap sizing ergonomics. An rfe will be filed to integrate CMS and the new default heap sizing ergo. 7. The minimum committed size of the old gen (OldSize) remains at 4m and the minimum committed size of the young gen (NewSize) increases to 4m. Note that these are the minimum, not initial sizes. NewSize is made common to all platforms. 8. Add a switch InitialHeapSize that can be used to set the initial committed size of the heap. Absent specification by InitialHeapSize, the initial committed size is max(1/64th of physical memory, OldSize + NewSize). 9. The default MaxHeapSize is raised from 64m to 96m. For systems with <= MaxHeapSize * MinRAMFraction of physical memory, the minimum heap size is 1/MinRAMFraction of physical memory. The default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m heap, a 128m box gets a 64m heap, a 96m box gets a 48m heap and a 64m box gets a 32m heap. The default values of MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for the client vms, 1g for 32-bit server vms and 32g for 64-bit server vms. The values for the server vms are the same as before. 256m is good for client because we want to bound resource utilization on client systems. Also, benchmarks runs showed no extra benefit from going to 512m heaps. 512m is the safe maximum for the serial collector.
29-10-2009
EVALUATION Ok.
01-10-2009