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

[sangheon.kim]

Hi all,

Gerard and I discussed about NewSizeThreadIncrease and we agreed to file 
a new CR[1] to handle it.
The reason is that under current validation, we can't detect the 
overflow. The flag NewSizeThreadIncrease is used with total of 
non-daemon threads after actual GC happened and the flag validation 
happens at the beginning of VM.

[1]: https://bugs.openjdk.java.net/browse/JDK-8144527

Thanks,
Sangheon

On 12/01/2015 09:49 AM, gerard ziemski wrote:
>
>
> 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