RFR: 8224878: Use JVMFlag parameters instead of name strings

John Rose john.r.rose at oracle.com
Tue May 28 21:22:53 UTC 2019


Reviewed.  This is a very good cleanup on
a mini-framework which used to be simple
and has grown hairy over the years.

I think you should add an expression evaluator
feature now to the flag framework.  …Not.
Just kidding!  It's plenty complicated already.
Thanks for making it more manageable.

— John

On May 28, 2019, at 10:15 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> To restrict the usages of flags fetched with find_flag_constrained (or whatever we'll call it), I changed it to return a const JVMFlag*. This way flags retrieved from that function won't be writable. If you want to write to a flag, you need to use the find_flag function, which does the appropriate checks (not locked, nor is_constant_in_binary).
> 
> Updated webrevs:
>  https://cr.openjdk.java.net/~stefank/8224878/webrev.02.delta
>  https://cr.openjdk.java.net/~stefank/8224878/webrev.02
> 
> Thanks,
> StefanK
> 
> On 2019-05-28 15:23, Stefan Karlsson wrote:
>> Hi David,
>> 
>> On 2019-05-28 15:05, David Holmes wrote:
>>> Hi Stefan,
>>> 
>>> Just in relation to the find_flag(name) versus find_flag(name, len) issue, I'm trying to see the simplest thing to "flip" so that it makes more sense, but to be honest I don't understand why we use the find_flag(name, len) form in the places that we do. For example:
>>> 
>>> JVMFlag::Error JVMFlag::boolAtPut(const char* name, size_t len, bool* value, JVMFlag::Flags origin) {
>>>    JVMFlag* result = JVMFlag::find_flag(name, len);
>>>    return boolAtPut(result, value, origin);
>>> }
>>> 
>>> won't find a locked flag - but why not? I don't see why this should be a function that only applies to unlocked flags. ??
>> 
>> The patch above actually removes that code:
>> -JVMFlag::Error JVMFlag::boolAtPut(const char* name, size_t len, bool* value, JVMFlag::Flags origin) {
>> -  JVMFlag* result = JVMFlag::find_flag(name, len);
>> -  return boolAtPut(result, value, origin);
>> -}
>> 
>> and left is the version that doesn't care if the flag is locked or not:
>> JVMFlag::Error JVMFlag::boolAtPut(JVMFlag* flag, bool* value, JVMFlag::Flags origin) {
>> 
>> However, now that you mention it, maybe that's unwise. Maybe we actually should check that we don't set locked (or is_constant_in_binary) flags.
>> 
>>> 
>>> But given we are talking about locked versus unlocked flags then find_flag_unlocked() would seem more appropriate than find_flag_unconstrained().
>> 
>> There's an extra dimension to this:
>> 
>>  896 // Search the flag table for a named flag
>>  897 JVMFlag* JVMFlag::find_flag(const char* name, size_t length, bool allow_locked, bool return_flag) {
>>  898   for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) {
>>  899     if (str_equal(current->_name, current->get_name_length(), name, length)) {
>>  900       // Found a matching entry.
>>  901       // Don't report notproduct and develop flags in product builds.
>>  902       if (current->is_constant_in_binary()) {
>>  903         return (return_flag ? current : NULL);
>>  904       }
>>  905       // Report locked flags only if allowed.
>>  906       if (!(current->is_unlocked() || current->is_unlocker())) {
>>  907         if (!allow_locked) {
>>  908           // disable use of locked flags, e.g. diagnostic, experimental,
>>  909           // etc. until they are explicitly unlocked
>>  910           return NULL;
>>  911         }
>>  912       }
>>  913       return current;
>>  914     }
>>  915   }
>>  916   // JVMFlag name is not in the flag table
>>  917   return NULL;
>>  918 }
>> 
>> it's not only locked flags that get returned. See lines 902-903. Do you still think find_flag_unlocked would be a better name?
>> 
>>> 
>>> More tomorrow ...
>> 
>> Thanks,
>> StefanK
>> 
>>> 
>>> Cheers,
>>> David
>>> 
>>> On 28/05/2019 10:44 pm, Stefan Karlsson wrote:
>>>> And here's the webrev:
>>>>   http://cr.openjdk.java.net/~stefank/8224878/webrev.01/
>>>> 
>>>> Thanks,
>>>> StefanK
>>>> 
>>>> On 2019-05-28 13:35, Stefan Karlsson wrote:
>>>>> Hi all,
>>>>> 
>>>>> Please review this patch to use JVMFlag parameters instead of name strings in the JVM flag handling code.
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224878
>>>>> 
>>>>> The intention is to reduce the places where the API uses "const char* name" parameters to describe a JVM flag, and instead use a JVMFlag* when performing various flag handling code. The places where we translate from "const char* name" to JVMFlag* has been pushed to the outer layers of the code, which explicitly uses the JVMFlag::find_flag functions.
>>>>> 
>>>>> This allows us to replace strcmp with simple JVMFlag pointer equality checks in jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp.
>>>>> 
>>>>> This gets rid of the need to store a typed pointer to the flag in jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp.
>>>>> 
>>>>> This gets rid of the the need to propagate the 'allow_locked' and 'return_flag' parameters down the call chain. For example, see the changes to JVMFlag::<type>At and JVMFlag::<type>AtPut:
>>>>> -  static JVMFlag::Error intAt(const char* name, int* value, bool allow_locked = false, bool return_flag = false)      { return intAt(name, strlen(name), value, allow_locked, return_flag); }
>>>>> +  static JVMFlag::Error intAt(const JVMFlag* flag, int* value);
>>>>>    static JVMFlag::Error intAtPut(JVMFlag* flag, int* value, JVMFlag::Flags origin);
>>>>> -  static JVMFlag::Error intAtPut(const char* name, size_t len, int* value, JVMFlag::Flags origin);
>>>>> -  static JVMFlag::Error intAtPut(const char* name, int* value, JVMFlag::Flags origin)   { return intAtPut(name, strlen(name), value, origin); }
>>>>> 
>>>>>   It changes the JVMFlag::find_flag API. The way it uses default values have a surprising effect for users of those functions. find_flag(name) searches among all flags (even locked and constants), while find_flag(name, strlen(name)) doesn't return locked or constants flags. To make it less likely to accidentally call the wrong version, this has been changed to the following:
>>>>> * JVMFlag::find_flag(name) - Fetches the flag if it is available (unlocked and not constant).
>>>>> * JVMFlag::find_flag_unrestricted(name) - Fetches the flag even if it is locked or a constant.
>>>>> 
>>>>> Removed the unused JVMFlag::wasSetOnCmdline.
>>>>> 
>>>>> Small cleanups
>>>>> - Renamed address_of_flag to flag_from_enum
>>>>> - Renamed local JVMFlag* variable from results to flag
>>>>> - Use initializer lists
>>>>> - Removed superfluous semicolons
>>>>> 
>>>>> I don't mind splitting patch up into more than one RFE, if that seems more appropriate.
>>>>> 
>>>>> Tested with:
>>>>> - test/hotspot/jtreg/runtime/CommandLine
>>>>> - tier1 (tier2-3 80% done)
>>>>> 
>>>>> Suggestions on other testing is appreciated.
>>>>> 
>>>>> Thanks,
>>>>> StefanK
> 



More information about the hotspot-runtime-dev mailing list