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