3rd rev: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments

Oracle derek.white at oracle.com
Wed Jan 21 15:05:09 UTC 2015


Thanks Gerard,


> On Jan 20, 2015, at 6:59 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> 
> hi Derek ,
> 
> Very, very nice code and thank you for taking the time to do a bit of code cleanup. I have just a few comments/suggestions below for the “arguments.cpp" file:
> 
> #1 Instead of
> 
>    { "MaxGCMinorPauseMillis", JDK_Version::jdk(8), JDK_Version::jdk(SpecialFlag::_removal_unscheduled)},
> 
> how about this:
> 
>    { "MaxGCMinorPauseMillis", JDK_Version::jdk(8), JDK_Version::jdk(JDK_Version::unscheduled())},
> 
> and move "bool is_removal_scheduled() const” API to JDK_Version class? It seems to me that any API that has to do with JDK version number should live in JDK_Version class.

How about "JDK_Version::undefined()" instead? That seems more generally useful and less option-specific
> 
> #2 Instead of
> 
>    .
>    .
>    .
>    { "CMSMarkStackSizeMax", JDK_Version::jdk(9), JDK_Version::jdk(10)},
>    { "CMSMarkStackSize", JDK_Version::jdk(9), JDK_Version::jdk(10)},
>    .
>    .
>    .
> 
> how about going back to the nice formatting we used to have like:
> 
>    .
>    .
>    .
>    { "CMSMarkStackSizeMax”,	JDK_Version::jdk(9), JDK_Version::jdk(10)},
>    { "CMSMarkStackSize”,	JDK_Version::jdk(9), JDK_Version::jdk(10)},
>    .
>    .
>    .
> 
> The formatted text seems so much nicer to read.

OK. I thought I did that. Must have gotten lost.
> #3 Where did the JDK version numbers in deprecated_jvm_flags table come from? Are we sure we got them right?
> 
I'll double check those. 
> 
> cheers

Thanks again.

- Derek


>> On 1/19/2015 12:56 PM, Derek White wrote:
>> Gerard found a few portability bugs. 3rd request's the charm.
>> 
>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.02
>> 
>> Reran jprt and jtreg.
>> 
>>  - Derek
>> 
>>> On 1/12/15 5:10 PM, Derek White wrote:
>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8066821
>>> 
>>> This webrev adds support for handling "deprecated" -XX options (options that still do something but are planned for removal) and "alias" options (alternate names for other -XX options) by simply adding entries to the deprecated_jvm_flags and/or aliased_jvm_flags tables. This follows the
>>> example of the existing obsolete_jvm_flags table.
>>> 
>>> This replaces a lot of ad-hoc and occasionally wrong code in arguments.cpp (including Arguments::check_deprecated_gc_flags) as well as supporting automatically disabling options after a certain version.
>>> 
>>> Removed Code:
>>>  - Removed global DefaultMaxRAMFraction, which was an "improper" alias for "MaxRAMFraction" (two variables that were roughly kept in sync vs. two names for the same variable).
>>>  - Arguments::check_deprecated_gc_flags().
>>>  - Alias handling code in Arguments::parse_each_vm_init_arg().
>>> It also avoids future ad-hoc and occasionally wrong code as new options get aliased and deprecated.
>>> 
>>> Tests:
>>> Deprecated and alias options can be tested by adding entries to tables in new tests:
>>>   VMAliasOptions.java
>>>   VMDeprecatedOptions.java
>>> 
>>> The new tests subsume these existing tests:
>>>   test/gc/startup_warnings/TestDefaultMaxRAMFraction.java
>>>   test/gc/startup_warnings/TestNoParNew.java 
>>> 
>>> 
>>> Tests run:
>>>     jprt
>>>     jtreg
>>> 
>>> Thanks,
>>> 
>>>  - Derek
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150121/3a3a4b96/attachment.html>


More information about the hotspot-gc-dev mailing list