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

[gerard ziemski]

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