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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150121/3a3a4b96/attachment.htm>
More information about the hotspot-gc-dev
mailing list