Pls review 6887571

Paul Hohensee Paul.Hohensee at Sun.COM
Wed Oct 28 12:26:06 PDT 2009


Excellent.  Thanks!

Y.S.Ramakrishna at Sun.COM wrote:
> See my previous email re treatment of CMS wrt the ergo heap sizing
> affected here. I am find, though, with that  happening is a separate CR.
> So I am fine with this going in in the current state (i.e. Paul's
> latest webrev as of this writing (webrev.04)).
>
> thanks.
> -- ramki
>
> On 10/28/09 08:25, Jon Masamitsu wrote:
>> Comment should probably say "initial heap size" instead of "minimum
>> heap size".
>>
>> 1357     if (!FLAG_IS_DEFAULT(InitialHeapSize)) {
>> 1358       // A minimum heap size was specified on the command line,
>>
>>
>> Instead of this,
>>
>> 2719   // Set heap size based on available physical memory.
>> 2720   // CMS uses its own heap size ergo.
>> 2721   if (!UseConcMarkSweepGC) {
>> 2722     set_heap_size();
>> 2723   }
>> 2724
>> 2725   if (UseParallelGC || UseParallelOldGC) {
>> 2726     // Set some flags for ParallelGC if needed.
>> 2727     set_parallel_gc_flags();
>> 2728   } else if (UseConcMarkSweepGC) {
>> 2729     // Set some flags for CMS
>> 2730     set_cms_and_parnew_gc_flags();
>> 2731   } else if (UseParNewGC) {
>> 2732     // Set some flags for ParNew
>> 2733     set_parnew_gc_flags();
>> 2734   } else if (UseG1GC) {
>> 2735     // Set some flags for garbage-first, if needed.
>> 2736     set_g1_gc_flags();
>> 2737   }
>>
>> consider
>>
>> if (UseConcMarkSweepGC) {
>>   // Set some flags for cms and ParNew.  If both
>>   // UseConcMarkSweepGC and UseParNewGC are set,
>>   // this is the call that should be done.
>>   set_cms_and_parnew_gc_flags();
>> } else {
>>   set_heap_size();
>>   if (UseParallelGC || UseParallelOldGC) {
>>     // Set some flags for ParallelGC if needed.
>>     set_parallel_gc_flags();
>>   } else if (UseParNewGC) {
>>     // Set some flags for ParNew
>>     set_parnew_gc_flags();
>>   } else if (UseG1GC) {
>>     // Set some flags for garbage-first, if needed.
>>     set_g1_gc_flags();
>>   }
>> }
>>
>>
>> I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM)
>> to the obsolete_jvm_flags[] in arguments.cpp.  For example
>>
>>   { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), 
>> JDK_Version::jdk(8) }
>>
>>
>> That's all.
>>
>>
>> On 10/27/09 16:01, Paul Hohensee wrote:
>>> .02 has the fix for line 1105.
>>>
>>> I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone
>>> else has another opinion.  I'm not proud. :)
>>>
>>> Thanks for the review, and for reviewing interim versions.
>>>
>>> Paul
>>>
>>> Jon Masamitsu wrote:
>>>> Paul,
>>>>
>>>> Just a couple of comments from the .01 version
>>>> of the webrev.  I haven't started the .02 version
>>>> yet so may have more comments after I do.
>>>>
>>>> Jon
>>>>
>>>> arguments.cpp
>>>>
>>>> 1105       InitialHeapSize = min_new + OldSize;
>>>>
>>>> Use FLAG_SET_ERGO()
>>>>
>>>> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize);
>>>>
>>>> Sometimes in the setting of the GC policies we like to
>>>> know how the flag was set.
>>>>
>>>> I like ErgoHeapSizeLimit instead of
>>>> MaxErgoHeapSize but just my preference.
>>>>
>>>>
>>>>
>>>> On 10/27/09 09:26, Paul Hohensee wrote:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>


More information about the hotspot-dev mailing list