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

Gerard Ziemski gerard.ziemski at oracle.com
Tue Jan 20 23:59:53 UTC 2015


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.


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


#3 Where did the JDK version numbers in deprecated_jvm_flags table come from? Are we sure we got them right?


cheers




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/20150120/73734fc0/attachment.html>


More information about the hotspot-gc-dev mailing list