RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options.
gerard.ziemski at oracle.com
Fri Jul 31 16:17:07 UTC 2015
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).
> So new consistent behavior is if a flag is *known* and *modifiable*
> the result should be the same with and without
> IgnoreUnrecognizedVMOptions flag.
> 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?
> 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
>> 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
>> and it was decided that we need a new flag that provides a better
>> alternative - that effort is now tracked by
>> Tested with test case from
>> https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset
>> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/
More information about the hotspot-dev