RFR: 8224878: Use JVMFlag parameters instead of name strings

Stefan Karlsson stefan.karlsson at oracle.com
Tue May 28 17:15:08 UTC 2019


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