Pls review 6887571

[Paul Hohensee]

6887571: Increase default heap config sizes

Webrev at

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

 From the CR description:

The default client vm heap config since ~2000 has been the equivalent 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
cause promotion of transient objects, thereby eventually provoking 
unnecessary
full GCs.

This change make the default heap config

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

I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but 
increases absolute
survivor space size 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, thereby increasing reducing the number 
of young collections.

JavaFX startup benchmark runs show an almost 11% improvement, while generic
client startup benchmark runs show up to 14% improvement.  Footprint 
increases
somewhat, ranging from 2% for noop to 37% for netbeans.

Thanks,

Paul