RFR(S): 8142341: GC: current flags need ranges to be implemented
sangheon.kim at oracle.com
Wed Dec 2 20:11:19 UTC 2015
Gerard and I discussed about NewSizeThreadIncrease and we agreed to file
a new CR 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.
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?
More information about the hotspot-dev