RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options.
gerard ziemski
gerard.ziemski at oracle.com
Fri Jul 31 17:15:08 UTC 2015
On 07/31/2015 11:36 AM, Vladimir Kozlov wrote:
> The table in JDK-8129855 looks good to me except #1.2.3. Why it is error?
>
> #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version
Fixed - it was an editing error, it was fine in my master table. Thank
you for verifying.
cheers
>
> Thanks,
> Vladimir
>
> On 7/31/15 9:17 AM, gerard ziemski wrote:
>>
>>
>> On 07/30/2015 09:41 PM, Vladimir Kozlov wrote:
>>> Yes, lets hear others opinion.
>>
>> Any other opinions?
>>
>>
>>>
>>> Note, your current changes should change 1.1.3 behavior too (should
>>> produce ERR).
>>
>> Correct, fixed.
>>
>>
>>>
>>> So new consistent behavior is if a flag is *known* and *modifiable*
>>> the result should be the same with and without
>>> IgnoreUnrecognizedVMOptions flag.
>>
>> Makes sense.
>>
>>
>>>
>>> You are also missing an other testing configuration - invalid usage
>>> of debug flag in product VM:
>>>
>>> -XX:DeoptimizeALot or -XX:CIStart=notnum
>>>
>>> Those should be ignored in product (produce OK).
>>
>> I have added tables #1.6, #1.7 and #1.8 to check malformed flags.
>> Tables #1.6 and #1.7 will have the new behavior
>> consistent with new and narrow IgnoreUnrecognizedVMOptions flag
>> interpretation(ex. ignore *unrecognized*, but *not
>> malformed*) as you suggested.
>>
>>
>> Is the table in https://bugs.openjdk.java.net/browse/JDK-8129855 the
>> right template now on which to base the
>> implementation?
>>
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 7/30/15 4:00 PM, gerard ziemski wrote:
>>>> (resending with tables formatted using plain text - the mailing list
>>>> sanitized my real tables. hopefully the plain text formatting will get
>>>> preserved, if not, please see the table in the bug's comments
>>>> section at
>>>> https://bugs.openjdk.java.net/browse/JDK-8129855)
>>>>
>>>> Thank you Dmitry and Vladimir for feedback. I have a follow-up
>>>> question
>>>> to Vladimir's feedback:
>>>>
>>>>> I think we need more detailed check in case of locked flags. We
>>>>> should
>>>>> bailout only for product vs develop and product vs notproduct
>>>>> combinations (last 2 cases in get_locked_message()). For diagnostic
>>>>> and experimental flags we should exit with error message - this flags
>>>>> are available in product and most likely a developer forgot to add
>>>>> unlock flag. If we ignore them a test will be executed differently
>>>>> than intended. Thanks, Vladimir
>>>>
>>>> So, you are asking for changing the current behavior? According to the
>>>> tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you
>>>> ask for is a new behavior. What you ask for is to have
>>>> "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked
>>>> experimental, diagnostic and commercial" flags, right?
>>>>
>>>> The issue JDK-8129855 only asks to restore behavior demonstrated by
>>>> case
>>>> #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open
>>>> to do the changes you ask for if that's the consensus.
>>>>
>>>> Please see the following test cases and verify that this is the
>>>> behavior
>>>> we want - if that's the case, then I will make the corresponding
>>>> change
>>>> and do an update to my webrev (which at moment fails #1.3.4, #1.3.5
>>>> and
>>>> #1.3.5 in table #1.3):
>>>>
>>>> ...
>>>>
>>>>
>>>> There was a brief email thread on this subject sometime ago at
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html
>>>>
>>>> and it was decided that we need a new flag that provides a better
>>>> alternative - that effort is now tracked by
>>>> https://bugs.openjdk.java.net/browse/JDK-8132545
>>>>
>>>> Tested with test case from
>>>> https://bugs.openjdk.java.net/browse/JDK-8130697,
>>>> https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset
>>>> hotspot"
>>>>
>>>> References:
>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8129855
>>>> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/
>>>>
>>>>
>>>> cheers
>>
>>
>
>
More information about the hotspot-dev
mailing list