RFR: 8184765: Dynamically resize SystemDictionary

[Gerard Ziemski]

hi David,

I humbly disagree.

The flag was only meant to be there temporarily, and the fact that the feature is turned ON by default here means that turning it OFF would be considered “experimental”, since we don’t want such option to be considered a valid product configuration.

Does that argument convince you?

If not, I’d rather remove the flag altogether.


cheers

> On Oct 30, 2017, at 10:50 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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