RFR: 8184765: Dynamically resize SystemDictionary

[coleen.phillimore at oracle.com]

On 10/31/17 3:10 PM, coleen.phillimore at oracle.com wrote:
>
> This looks good now.  The table would also limit the number of 
> resizing events, until you hit the max.
Sorry, modulo making the flag a diagnostic flag.
thanks,
Coleen
>
> 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
>>
>>
>