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

[Vladimir Kozlov]

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

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
>
>