RFR (S): JDK-8129855: -XX:+IgnoreUnrecognizedVMOptions hides out of range VM options.

[gerard ziemski]

Thank you Dan!

I fixed the comments and filed https://bugs.openjdk.java.net/browse/JDK-8140359 as a follow-up to address 
get_locked_message_ext()


cheers


On 10/22/2015 12:04 PM, Daniel D. Daugherty wrote:
> On 10/22/15, 10:26 AM, gerard ziemski wrote:
>> hi all,
>>
>> Here is a rev2 updated with fixes based mainly on Dan's feedback. It has 3 changes compared to rev1:
>>
>> #1 Fixed IgnoreUnrecognizedVMOptions.java test cases by correctly setting the flags [Dan Daugherty]
>>
>> #2 Added another set of test cases, and rearranged them to keep types together.
>>
>> #3 Fixed test/compiler/membars/DekkerTest since now that the IgnoreUnrecognizedVMOptions works differently we have to
>> re-arrange the flags to make CICompilerCount=1 a valid value.
>>
>>
>> http://cr.openjdk.java.net/~gziemski/8129855_rev2
>
> src/share/vm/runtime/arguments.cpp
>      No comments.
>
> src/share/vm/runtime/globals.cpp
>      L336:   get_locked_message_ext(buf, buflen);
>      L337:   return Flag::NONE;
>          It still feels strange to not get a return value from
>          get_locked_message_ext() and always return Flag::NONE
>          in this case.
>
>          If not addressed here, it would be good to file a follow
>          up bug that clarify how the extension mechanism fits in
>          with the base mechanism.
>
> src/share/vm/runtime/globals.hpp
>      No comments.
>
> test/compiler/membars/DekkerTest.java
>      Perfect example of why left-to-right order eval means something.
>      No other comments.
>
> test/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java
>      L90: #1.4 develop & notproduct flag on product VM:
>      L91: develop & !product_build        notproduct & !product_build
>      L96: if (product) {
>          The comment doesn't match the test code. This is not
>          a !product_build config.
>
>      L119: #1.6 malformed develop & notproduct flag on product VM:
>      L120: develop & !product_build          .notproduct & !product_build
>      L125: if (product) {
>          The comment doesn't match the test code. This is not
>          a !product_build config.
>
>          Also L120 has '.notproduct' should be 'notproduct'.
>
> Thumbs up. If you fix the above comment mis-matches, I don't
> need to see another webrev.
>
> Dan
>
>
>>
>>
>> cheers
>>
>> On 09/28/2015 04:55 PM, gerard ziemski wrote:
>>> hi all,
>>>
>>> We are fixing how IgnoreUnrecognizedVMOptions treats those flags whose values are out of range. Before the fix, the VM
>>> would continue even if flag’s value was out of range, ex:
>>>
>>> java_old -XX:+IgnoreUnrecognizedVMOptions -XX:MinTLABSize=0 -version
>>> size_t MinTLABSize=0 is outside the allowed range [ 1 ... 4294967295 ]
>>> java version "1.9.0-internal-fastdebug"
>>> Java(TM) SE Runtime Environment (build 1.9.0-internal-fastdebug-20150624183527.jesper.main2rt-b00)
>>> Java HotSpot(TM) Server VM (build 1.9.0-internal-fastdebug-20150624183527.jesper.main2rt-b00, mixed mode)
>>>
>>> now, we correctly exit the VM with an error, ex:
>>>
>>> java_new -XX:+IgnoreUnrecognizedVMOptions -XX:MinTLABSize=0 -version
>>> size_t MinTLABSize=0 is outside the allowed range [ 1 ... 18446744073709551615 ]
>>> Improperly specified VM option 'MinTLABSize=0'
>>> Error: Could not create the Java Virtual Machine.
>>> Error: A fatal exception has occurred. Program will exit.
>>>
>>> In addition IgnoreUnrecognizedVMOptions nows strictly follows the spec as outlined in JDK-8129855. The behavior changes
>>> depending on whether the build is product or debug.
>>>
>>> We also introduce a new test that verifies all known use cases that we care about.
>>>
>>> References:
>>>       bugid: https://bugs.openjdk.java.net/browse/JDK-8129855
>>>      webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0
>>> discussion: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html
>>>
>>> Passes "JPRT hotspot" and "RBT testlist,noncolo.testlist quick"
>>>
>>>
>>> cheers
>>>
>>
>