IgnoreUnrecognizedVMOptions and badly specified options
Stefan Karlsson
stefan.karlsson at oracle.com
Fri Jun 26 08:59:28 UTC 2015
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