IgnoreUnrecognizedVMOptions and badly specified options

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Jun 25 17:09:48 UTC 2015


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



More information about the hotspot-dev mailing list