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