RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing

[sangheon.kim]

On 09/23/2015 04:23 PM, Kim Barrett wrote:
> On Sep 23, 2015, at 5:00 PM, sangheon.kim <sangheon.kim at oracle.com> wrote:
>>>>> src/share/vm/gc/g1/g1_globals.hpp
>>>>>   169   develop(intx, G1RSetRegionEntriesBase, 256,                               \
>>>>>   173   product(intx, G1RSetRegionEntries, 0,                                     \
>>>>>   179   develop(intx, G1RSetSparseRegionEntriesBase, 4,                           \
>>>>>   184   product(intx, G1RSetSparseRegionEntries, 0,                               \
>>>>>   240   product(uintx, G1ConcRefinementThreads, 0,                                \
>>>>>
>>>>> All of these have their max range value changed to be divided by 4.
>>>>> What's this about?  What is this magic "4"?
>>>> 'G1RSetRegionEntries', 'G1RSetSparseRegionEntries' and 'G1ConcRefinementThreads' are finally multiplied by pointer size.
>>>> So we need to divide by 4 for 32bit to avoid overflow. We don't need for 64bit but I thought it will be enough for 64bit.
>>>> 'G1RSetRegionEntriesBase' and 'G1RSetSparseRegionEntriesBase' changed to have same range as 'G1RSetRegionEntries' and 'G1RSetSparseRegionEntries’.
>>> Dividing by 4 doesn't account for being multiplied by pointer size on
>>> a 64bit platform.
>> You are right. This is limitation for 32bit.
>> Both 'jint' and 'intx' are 32bit for 32bit platform and these options are used for 'size_t' type parameter after multiplying by pointer size.
>> So we need to divide by 4 on 32bit platform.
>> When it comes to 64bit platform, we don't need to divide by 4 as 'size_t' is big enough to cover 'max_jint * 8'.
>> But I think that value divided by 4 would be enough for 64bit platform.
>>
>> Jon also pointed '4' seems strange, so I suggested to use 'jintSize'.
>> What do you think?
>>
>>> In light of that, I don't understand this part of
>>> your response: "We don't need for 64bit but I thought it will be
>>> enough for 64bit."
>> I think I explained above.
> I see now.  jintSize would be better than 4.  But I think even better would be pointer size,
> though I haven’t found an existing constant for that.  Maybe sizeof(address)?
We have 'const int wordSize = sizeof(char*)'.

> The only
> disadvantage to that is the max value is then smaller on 64bit platforms than on 32bit
> platforms.  I doubt the difference is interesting in practice though.
I agree that there's no big difference in practice.
I just wanted to avoid to have smaller upper limit for 64bit platforms.
But if you prefer to use 'wordSize' instead of '4', I'm fine. It would 
give better readability.

Thanks,
Sangheon


>
>