IgnoreUnrecognizedVMOptions and badly specified options

[Gerard Ziemski]

I will be happy to take a look.


cheers

On 6/25/2015 12:09 PM, Daniel D. Daugherty wrote:
> I'm pretty sure that bug was filed this morning:
>
> JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly 
> specified VM options.
> https://bugs.openjdk.java.net/browse/JDK-8129855
>
> Michail was reading your mind...
>
> Dan
>
>
> On 6/25/15 11:06 AM, Vladimir Kozlov wrote:
>> File bug on runtime (who handles flags verification this days?) with 
>> your suggestion.
>>
>> Thanks,
>> Vladimir
>>
>> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote:
>>> Hello Vladimir,
>>>
>>> Thank you for explanation. I just was bit confused about valid VM 
>>> options but which improperly specified.
>>> I look at the Arguments::process_argument function in 
>>> src/share/vm/runtime/arguments.cpp module and noticed one thing:
>>>
>>>   817 bool Arguments::process_argument(const char* arg,
>>>   818     jboolean ignore_unrecognized, Flag::Flags origin) {
>>>   819
>>>   820   JDK_Version since = JDK_Version();
>>>   821
>>>   822   if (parse_argument(arg, origin) || ignore_unrecognized) {
>>>   823     return true;
>>>   824   }
>>> ...
>>>   850   // For locked flags, report a custom error message if 
>>> available.
>>>   851   // Otherwise, report the standard unrecognized VM option.
>>>   852   Flag* found_flag = Flag::find_flag((const char*)argname, 
>>> arg_len, true, true);
>>>   853   if (found_flag != NULL) {
>>>   854     char locked_message_buf[BUFLEN];
>>>   855 found_flag->get_locked_message(locked_message_buf, BUFLEN);
>>>   856     if (strlen(locked_message_buf) == 0) {
>>>   857       if (found_flag->is_bool() && !has_plus_minus) {
>>>   858         jio_fprintf(defaultStream::error_stream(),
>>>   859           "Missing +/- setting for VM option '%s'\n", argname);
>>>   860       } else if (!found_flag->is_bool() && has_plus_minus) {
>>>   861         jio_fprintf(defaultStream::error_stream(),
>>>   862           "Unexpected +/- setting in VM option '%s'\n", argname);
>>>   863       } else {
>>>   864         jio_fprintf(defaultStream::error_stream(),
>>>   865           "Improperly specified VM option '%s'\n", argname);
>>>   866       }
>>>   867     } else {
>>>   868       jio_fprintf(defaultStream::error_stream(), "%s", 
>>> locked_message_buf);
>>>   869     }
>>>   870   } else {
>>>   871     jio_fprintf(defaultStream::error_stream(),
>>>   872                 "Unrecognized VM option '%s'\n", argname);
>>>   873     Flag* fuzzy_matched = Flag::fuzzy_match((const 
>>> char*)argname, arg_len, true);
>>>   874     if (fuzzy_matched != NULL) {
>>>   875       jio_fprintf(defaultStream::error_stream(),
>>>   876                   "Did you mean '%s%s%s'? ",
>>>   877                   (fuzzy_matched->is_bool()) ? "(+/-)" : "",
>>>   878                   fuzzy_matched->_name,
>>>   879                   (fuzzy_matched->is_bool()) ? "" : "=<value>");
>>>   880     }
>>>   881   }
>>>   882
>>>   883   // allow for commandline "commenting out" options like 
>>> -XX:#+Verbose
>>>   884   return arg[0] == '#';
>>>   885 }
>>>
>>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then 
>>> "ignore_unrecognized" will be true and "if" statement on line
>>> 822 will always be true.
>>> I just think that a better place to check "ignore_unrecognized" is 
>>> on "else" branch on line 867(for locked flags) and on
>>> "else" branch on line 870(where we actually found unrecognized 
>>> option). If "ignore_unrecognized" is true, then return
>>> true in this case, otherwise execute code in these "else" branches. 
>>> It's my thoughts about that. In this case improperly
>>> specified options will be catched(lines 857-866).
>>>
>>> Thanks,
>>> Dmitry
>>>
>>>
>>> On 25.06.2015 17:45, Vladimir Kozlov wrote:
>>>> It is not intentional but difficult to implement.
>>>> It was added to allow specify options which are not defined in 
>>>> running VM.
>>>> For example when C2 option is specified but Client VM (which has 
>>>> only C1) is run.
>>>> We can do more smarter things here, I agree, by trying to verify 
>>>> options before ignoring it.
>>>> But it will not help with misspelled options, I think.
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote:
>>>>> Hello,
>>>>>
>>>>> Working with JVM command line options I noticed that 
>>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad
>>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized 
>>>>> options, but it also allow to ignore improperly
>>>>> specified VM Options which are processed in general way, i.e. 
>>>>> "-XX:" options processed by Arguments::process_argument
>>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module).
>>>>>
>>>>> I will be very appreciated if someone can describe this behavior 
>>>>> or state that this is intentional.
>>>>>
>>>>> Example for numeric and boolean options:
>>>>> 1) Bad numeric option with and without 
>>>>> "-XX:+IgnoreUnrecongnizedVMOptions"
>>>>> java -XX:MaxRAMFraction=-1 -version
>>>>> Improperly specified VM option 'MaxRAMFraction=-1'
>>>>> Error: Could not create the Java Virtual Machine.
>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>
>>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version
>>>>> java version "1.8.0_40"
>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>>>>>
>>>>> 2) Bad boolean option with and without 
>>>>> "-XX:+IgnoreUnrecongnizedVMOptions"
>>>>> java -XX:UseG1GC -version
>>>>> Missing +/- setting for VM option 'UseG1GC'
>>>>> Error: Could not create the Java Virtual Machine.
>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>
>>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version
>>>>> java version "1.8.0_40"
>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>>>>>
>>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, 
>>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are
>>>>> ignored. I don't know is this behavior intentional or not, but 
>>>>> HotSpot works in that way.
>>>>>
>>>>> So, can someone tell me this is intentional? Or this behavior is 
>>>>> wrong?
>>>>>
>>>>> Thank you,
>>>>> Dmitry
>>>>>
>>>>>
>>>
>
>