IgnoreUnrecognizedVMOptions and badly specified options
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 26 15:24:26 UTC 2015
I agree with this suggestion. Make it ccstrlist so we can specify list
of flags. But then the name should be different - "Unrecognized" is
misleading in such case I think.
Thanks,
Vladimir
On 6/26/15 1:59 AM, Stefan Karlsson wrote:
> On 2015-06-26 08:00, Bengt Rutisson wrote:
>>
>> 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.
>
> Yes, I've also suggested this a couple of times. Maybe it's time to
> create an RFE?
>
> StefanK
>
>>
>> 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