RFR: 8184765: Dynamically resize SystemDictionary

[David Holmes]

Hi Gerard,

The flag should not be experimental - enabling resizable tables is not 
an experiment that the user is controlling, it is the default behaviour 
that we intend to occur. The flag is there to turn it off if for some 
reason this doesn't work - the flag should be a product flag.

The flag also requires a CSR request.

Thanks,
David

On 31/10/2017 9:28 AM, Gerard Ziemski wrote:
> hi Coleen,
> 
> I updated the webrev to rev3
> 
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8184765
> 
> webrev:
> http://cr.openjdk.java.net/~gziemski/8184765_rev3
> 
> 
>> On Oct 30, 2017, at 10:36 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>>
>> On 10/30/17 11:24 AM, Gerard Ziemski wrote:
>>> hi Coleen,
>>>
>>>
>>>> On Oct 30, 2017, at 10:12 AM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>> Hi Gerard,
>>>>
>>>> This looks great.  One small question:
>>>> + // straight forward brute force
>>>> + inline static int _next_prime(int n) {
>>>> +   int p = n;
>>>> +   for (int i = n; i < (n * n); i++) {
>>>> +     if ((i % 2) != 0) {
>>>> +       p = i;
>>>> +       break;
>>>> +     }
>>>> +   }
>>>> +   return p;
>>>> + }
>>>>
>>>> Is this how you calculate next prime?  Wouldn't you check if it can mod by 3 and 5 as well?
>>> As long as it’s not even i.e. mod 2 (and strictly speaking larger than 1). 3 and 5 are prime, so no need to check them.
>>
>> If you passed in 214 (2*107), 215 would look prime but it's not.   I think the prime table would be better and limit resizing occurrences.
> 
> Thank you for catching the problem.
> 
> I went with a simple table of prime numbers (as was used before), since Coleen pointed out to me that the resizing will occur at safe point, so we want to keep the time used to find next prime to a minimum (though resizing is probably so expensive anyways, would it really matter?)
> 
> 
> cheers
> 
>