RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize
Jesper Wilhelmsson
jesper.wilhelmsson at oracle.com
Tue Jan 15 10:25:58 PST 2013
Erik,
I would prefer solution number two for the same reason that I moved my
old gen size fix out of arguments.cpp, the code in Arguments don't know
about generations and if we can avoid adding that knowledge I think we
should avoid it. CollectorPolicy already know about generations and I
think it is the right place for this code.
/Jesper
On 15/1/13 3:45 PM, Erik Helin wrote:
> Jon,
>
> On 01/14/2013 09:41 PM, Jon Masamitsu wrote:
>> Change looks good.
>
> Thanks!
>
> On 01/14/2013 09:41 PM, Jon Masamitsu wrote:
>> Do you think it would
>> fit better in TwoGenCollectorPolicy::initialize_flags()
>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to
>> add it also to G1CollectorPolicy::initialize_flags()
>> or do some refactoring of the various initialize_flags().
>
> I don't want to duplicate the code by adding it to both
> G1CollectorPolicy and GenCollectorPolicy, but I agree that
> Arguments::set_heap_size might not be the best place for it.
>
> I've tried a few different approaches, and also discussed with Bengt
> and Jesper, and I think that one of the following approaches is the
> way to go:
>
> 1. Add a new function, Arguments::set_heap_generation_sizes(), that
> sets MaxNewSize. Jesper could add his code for OldSize in this
> function as well.
>
> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/
>
> 2. Add the code to CollectorPolicy::initialize_flags().
>
> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/
>
> Both options have drawbacks:
>
> It does not feel right to add a function to arguments.cpp that handles
> GC specific flags. On the other hand, this has already been done quite
> extensively, but that is not an excuse for continue doing it.
>
> Adding the code to CollectorPolicy breaks the abstraction that
> CollectorPolicy is not supposed to know about generational heap
> collectors (although this has already happened, see
> CollectorPolicy::initialize_size_info).
>
> Out of these two, I would prefer the first option (adding a new
> function in arguments.cpp) and I think both options are better than
> duplicating the code.
>
> Which option do you prefer? Or would you prefer another solution?
>
> Thanks,
> Erik
>
>> Jon
>>
>>
>> On 01/12/13 00:27, Erik Helin wrote:
>>> Hi all,
>>>
>>> this change sets MaxNewSize to always be less than or equal to
>>> MaxHeapSize. The current default value is max_uintx.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/
>>>
>>> RFE:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989
>>>
>>> Analysis:
>>> The change should not affect the existing code. The case that has to
>>> be analyzed is when MaxNewSize is not set on the command line, since
>>> the update of MaxNewSize is guarded by "if
>>> (FLAG_IS_DEFAULT(MaxNewSize))".
>>>
>>> MaxNewSize is only used in the following files:
>>>
>>> - g1CollectorPolicy.cpp:
>>> Guards all the usage of MaxNewSize in if statements:
>>>
>>> if (FLAG_IS_CMDLINE(MaxNewSize)) {
>>> ...
>>> }
>>>
>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect
>>> this code path.
>>>
>>> - arguments.cpp:
>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements.
>>> Otherwise, only writes new values to MaxNewSize that are not based on
>>> the value of MaxNewSize. This code is not affected since the value of
>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected.
>>>
>>> - collectorPolicy.cpp:
>>> MaxNewSize is used in a couple of places:
>>>
>>> if (NewSize > MaxNewSize) {
>>> MaxNewSize = NewSize;
>>> }
>>>
>>> If both NewSize and MaxNewSize have their default values, then
>>> NewSize is ScaleForWordSize(1*M) which will always be less than
>>> MaxNewSize which now is MaxHeapSize. The semantics of the if
>>> statement is only changed if NewSize is set on the command line to a
>>> value larger than MaxHeapSize, which is not a valid case.
>>>
>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) {
>>> ...
>>> } else {
>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size());
>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize);
>>> }
>>>
>>> This "if" check will still follow the "else" branch in the default
>>> case, just as before, since FLAG_SET_DEFAULT is used in this change.
>>> The semantics of the calculation in the else branch is also
>>> preserved,
>>> since MAX2(max_new_size, NewSize) will still always be less than
>>> MaxNewSize for all valid values of NewSize.
>>>
>>> Testing:
>>> Before the change:
>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize'
>>> uintx MaxHeapSize := 2017460224 {product}
>>> uintx MaxNewSize = 18446744073709486080 {product}
>>>
>>> After the change:
>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize'
>>> uintx MaxHeapSize := 2017460224 {product}
>>> uintx MaxNewSize = 2015428608 {product}
>>>
>>> JPRT
>>>
>>> Thanks,
>>> Erik
>
More information about the hotspot-dev
mailing list