RFR: 8316180: Thread-local backoff for secondary_super_cache updates [v5]
Aleksey Shipilev
shade at openjdk.org
Wed Sep 27 17:08:16 UTC 2023
On Wed, 27 Sep 2023 16:39:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
>> I don't think the discriminating factor for calling an option "diagnostic" or "experimental" is its default value. Rather it is its target use.
>>
>> As per `globals.hpp`:
>>
>>
>> // DIAGNOSTIC options are not meant for VM tuning or for product modes.
>> // They are to be used for VM quality assurance or field diagnosis
>> // of VM bugs.
>>
>> // EXPERIMENTAL flags are in support of features that may not be
>> // an officially supported part of a product, but may be 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.
>>
>>
>> ...and this one is obviously the experimental performance feature.
>
> I referred to default value because in your particular case it controls whether the feature is turned on or off. Calling a feature experimental when it is unconditionally turned on in product builds looks a bit weird, doesn't it?
Well, maybe :) One might ask another question: if I am experimenting with the value of this option, by switching from non-zero default to another non-zero value for performance evaluation in the field, is it really "diagnostic"? I think "experimental" captures the whole thing better. But I can change to diagnostic, if you insist.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15718#discussion_r1338935617
More information about the hotspot-dev
mailing list