RFR: 8184765: Dynamically resize SystemDictionary

[coleen.phillimore at oracle.com]

This looks good now.  The table would also limit the number of resizing 
events, until you hit the max.

thanks,
Coleen

On 10/30/17 7:28 PM, 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
>
>