IgnoreUnrecognizedVMOptions and badly specified options

[Vladimir Kozlov]

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
>>>
>>>
>