IgnoreUnrecognizedVMOptions and badly specified options
Bengt Rutisson
bengt.rutisson at oracle.com
Fri Jun 26 06:00:56 UTC 2015
Hi all,
Just one more thought if we are thinking about making changes to the
IgnoreUnrecognizedVMOptions flag.
I am not a big fan of this flag since I think it just goes to show that
we don't have enough control over our testing. As I understand it the
main reason for the introduction of this flag was that when compressed
oops was implemented we had no way of controlling which tests were run
on 32 bit platforms (where the UseCompressedOops flag is not available)
or o 64 bit platforms.
I think it is unfortunate that we don't have better control of our
testing. But one way of at least increasing the control would be to make
IgnoreUnrecognizedVMOptions more specific. I would suggest that we
change it to take a named argument that should be ignored.
Something like:
-XX:IgnoreUnrecognizedVMOption=UseCompressedOops
That way it would not hide other issues in our testing. As it is now we
run a lot of our testing with IgnoreUnrecognizedVMOptions which means
that we don't find tests that need to be updated when we for example
remove a command line option.
Maybe it is a side track, but I wanted to mention it in this discussion.
Bengt
On 2015-06-26 07:39, David Holmes wrote:
> On 26/06/2015 3:13 AM, Dmitry Dmitriev wrote:
>> Thank you Dan! The bug states about changed behaviour but it relates to
>> the current implementation of IgnoreUnrecongnizedVMOptions flag and I
>> think it can be fixed by this RFR.
>
> As I added to the/a bug report I think we need a very clear spec on
> how all these aspects of option checking should interact - what should
> be ignored by IgnoreUnrecognizedVMOptions? Is a badly formed option
> "unrecognized"? A flow chart covering all the possibilities and the
> precedence would make it a lot easier to validate the code.
>
> Cheers,
> David
>
>> On 25.06.2015 20:09, 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...
>> No magic here, we discuss this topic today :) I am become curious about
>> that behaviour, since this code exit for a long time.
>>
>> Regards,
>> Dmitry
>>
>>>
>>> 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