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