RFR(S): 8142341: GC: current flags need ranges to be implemented

[gerard ziemski]

On 11/30/2015 07:33 PM, sangheon.kim wrote:
>>
>>>
>>> src/share/vm/runtime/globals.hpp lines:
>>> 3419   product(uintx, TLABRefillWasteFraction, 64,                            \
>>> 3420           "Maximum TLAB waste at a refill (internal fragmentation)")        \
>>> 3421           range(1, max_juint)                                               \
>>>
>>>
>>> -------------
>>> #6 We multiply NewSizeThreadIncrease later, like
>>>
>>>   size_t thread_increase_size = threads_count * NewSizeThreadIncrease;
>>>
>>> so the range's max needs to be smaller than max_uintx by some large enough constant (MAX thread count?)
>> You are right.
>> We don't have any problem without constraint function but it would be better to have one.
>> I will post next webrev soon with this constraint function.
> Looking at the code again, it is hard to add constraint function for this flag.
> When we run the constraint function('threads_count' is zero at this time), we don't know how many non-daemon threads
> will be running.
> i.e. 'size_t thread_increase_size = threads_count * NewSizeThreadIncrease; ' is executed after GC is happened and the
> flag validation is occurred much earlier.
> And as we are using both MIN/MAX macro, I think there will be no value range problem with this flag.
> What do you think about this?

Our SQE testing framework for ranges will use the MAX value from the range guranteed, so our testing will hit this for sure.

Should we perhaps then at least define the range as (1, max_juint/2048) or some other reasonable value instead of 2048?


cheers