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

gerard ziemski gerard.ziemski at oracle.com
Fri Oct 23 15:19:35 UTC 2015


Thank you.


On 10/23/2015 07:47 AM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> Rev2 looks good to me!
>
> Regards,
> Dmitry
>
> On 22.10.2015 20:34, gerard ziemski wrote:
>> 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
>>>>>
>>>>
>>>
>
>


More information about the hotspot-dev mailing list