Pls review 6887571
Paul Hohensee
Paul.Hohensee at Sun.COM
Wed Oct 28 12:59:35 PDT 2009
I've filed 6896099 to track CMS and default ergo integration.
Paul Hohensee wrote:
> 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