RFR: 8024137 - Flags should be set using the proper macro

Jon Masamitsu jon.masamitsu at oracle.com
Tue Jul 12 18:46:03 UTC 2016



On 7/12/2016 3:21 AM, Jesper Wilhelmsson wrote:
> Den 12/7/16 kl. 05:54, skrev Jon Masamitsu:
>>
>>
>> On 7/11/2016 3:14 PM, Jesper Wilhelmsson wrote:
>>> Hi Jon,
>>>
>>> Den 11/7/16 kl. 20:47, skrev Jon Masamitsu:
>>>> Jesper,
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/src/share/vm/gc/shared/collectorPolicy.cpp.frames.html 
>>>>
>>>>
>>>>
>>>>
>>>>  361   if (OldSize < old_gen_size_lower_bound()) {
>>>>  362     FLAG_SET_ERGO(size_t, OldSize, old_gen_size_lower_bound());
>>>>  363   }
>>>>  364   if (!is_size_aligned(OldSize, _gen_alignment)) {
>>>>  365     FLAG_SET_ERGO(size_t, OldSize, align_size_down(OldSize,
>>>> _gen_alignment));
>>>>
>>>>
>>>> If OldSize has to be adjusted for both lower bound and alignment,
>>>> what gets saved as the previous value?
>>>
>>> There is no difference in what is saved as the previous value due to 
>>> this
>>> change as far as I can see.
>>
>> I understand that to mean that the previous value saved by the first 
>> use of
>> FLAG_SET_ERGO
>> is not changed when FLAG_SET_ERGO is used a second time.   In this 
>> case at 362
>> the value set
>> on the command line is saved and the minimum adjusted value is set in 
>> OldSize.
>> Then at
>> 365 the previous value is still the value set on the command line and 
>> OldSize is
>> set to an aligned value.
>>
>> If that is so, then the change looks good.
>
> I assume you are referring to the tracing framework's tracking of flag 
> changes? This tracks all changes, not just the last one. But since the 
> old code did not use FLAG_SET_ERGO no change was tracked at all in 
> this case, no old value was saved. Now we track both changes and store 
> both old values in an event each.
>
> In the cases where the old code would change OldSize later using 
> FLAG_SET_ERGO (for instance in line 395) the old value stored could be 
> the result of alignment etc and would appear to come out of thin air.
>
> So my statement that there is no difference was not telling the whole 
> truth, but this is a change to the better :)
>
>
> I found another case where we could clean up the code. The variable 
> _max_heap_size_cmdline in CollectorPolicy can be removed since we 
> already know if the flag was set on the command line or not.
>
>
> There is a new webrev with this change included here:
> http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.02/

Thanks for the explanation.

All changes look good.

Jon

>
> Thanks,
> /Jesper
>
>>
>> Reviewed.
>>
>> Jon
>>
>>> /Jesper
>>>
>>>>
>>>> Jon
>>>>
>>>> On 06/21/2016 01:01 PM, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this change to make the GC ergonomics use 
>>>>> FLAG_SET_ERGO()
>>>>> instead of setting values directly in flags. This change builds on 
>>>>> the fix for
>>>>> JDK-8048093 and assumes that we will remember that the flags was 
>>>>> set on the
>>>>> command line.
>>>>>
>>>>> If you know of any other places where we assign a flag directly 
>>>>> without using
>>>>> FLAG_SET_ERGO() please let me know since it would make sense to 
>>>>> change all
>>>>> these places in this change.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8024137
>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>>>
>>>>
>>



More information about the hotspot-gc-dev mailing list