Pls review 6887571

[Paul Hohensee]

6887571: Increase default heap config sizes

Webrev here

http://cr.openjdk.java.net/~phh/6887571/webrev.01/

Some background:

The default client vm heap config since 2000 for sparc32 has been the 
equivalent of

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

and for 32-bit x86

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

OldSize and NewSize are the initial committed sizes of the old and young 
generations
respectively.  A minor gc is required to increase the committed size of 
the young gen,
while 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 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 a small young gen size increases 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.

This change extends 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. I added 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.  I replaced
DefaultMaxRAM with MaxErgoHeapSize for the latter purpose.  I added 
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.

5. The other Default* switches have been stripped of the "Default" 
prefix, since to me 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.  I left DefaultMaxRAMFraction as a synonym for 
MaxRAMFraction for
the moment because QA uses it.  When they change to MaxRAMFraction, I 
intend to remove
DefaultMaxRAMFraction.

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 (I know: I tried it), heap 
sizing ergonomics.

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. I added 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 
1/64th of physical memory
or OldSize + NewSize, whichever is larger.

9. I cleaned up some formatting, esp. in globals.hpp.

10. The default MaxHeapSize is raised from 64m to 96m.  For systems with 
<= MaxHeapSize
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, 
as does a 128m
box, but 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.  I picked 256m for client because I wanted 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.

Thanks,

Paul