RFR: 8184765: Dynamically resize SystemDictionary

David Holmes david.holmes at oracle.com
Wed Nov 1 01:42:35 UTC 2017


On 1/11/2017 4:39 AM, coleen.phillimore at oracle.com wrote:
> On 10/31/17 12:39 PM, John Rose wrote:
>> On Oct 30, 2017, at 8:50 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> 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
>>
>> This describes a diagnostic flag, not a product flag.  We mask those
>> flags to avoid polluting the list of true product flags with 
>> diagnostic hooks.

I can live with it being a diagnostic flag ...

>>> - the flag should be a product flag.
>>
>> Hence, it should be a diagnostic flag, if we think there is a long-term
>> diagnostic benefit to turning it off.  Otherwise it should be removed as
>> Gerard suggests.  Diagnosis could be for either bugs or performance.
>>
>> If there is a non-diagnostic reason, where we expect a user to flip it
>> more or less permanently for their use case, it could be product.

That's really the unknown part. As usual we think a change will be to 
the benefit of all, but we can't be certain of that.

> I agree this should be a diagnostic flag.   Technically we shouldn't 
> need it because this feature has been well developed and tested, but 
> we've been erring on the side of caution lately.
> 
> Do we still need a CSR for the diagnostic flag?

All flag additions/removals/modification require a CSR request.

>>
>> Experimental flags should be short-lived.

// experimental flags are in support of features that are not
//    part of the officially supported product, but are available
//    for experimenting with. They could, for example, be performance
//    features that may not have undergone full or rigorous QA, but 
which may
//    help performance in some cases and released for experimentation
//    by the community of users and developers. This flag also allows one to
//    be able to build a fully supported product that nonetheless also
//    ships with some unsupported, lightly tested, experimental features.

Many of our experimental flags are long-lived. Perhaps it is time for a 
cull?

Thanks,
David

>>
> 
> Hopefully the diagnostic flag should be short-lived as well.
> 
> Thanks,
> Coleen
>> — John
> 


More information about the hotspot-runtime-dev mailing list