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

[Kim Barrett]

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)?  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.