RFR (smallish?) 8061611: Remove deprecated command line flags
Bengt Rutisson
bengt.rutisson at oracle.com
Mon Dec 15 12:51:23 UTC 2014
Hi Derek,
On 2014-12-12 15:35, Derek White wrote:
> This is a request for final re-review.
>
> Updated for comments, and added regression test for arguments. This
> test is a bit overkill for this bug, but it's extensible for other
> deprecated and aliased options.
>
> Re-merged with tree.
>
> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/
The code changes look good to me.
A few comments about the test.
I don't think it is worth testing that the removed flags produce error
messages. Starting a VM takes some time and doing it 13 times just to
check that no one by mistake added the flags back seems like a waste of
resources to me. The risk that the flags are suddenly added back is
almost zero, right?
I am also not convinced that a general and extensible test is the way to
go here. I think I would prefer a more specific test for the flags that
were deprecated now. For tests I think it is more important that the
tests are easily readable and understandable than that code duplication
is avoided. Thus, I strongly prefer small but specific tests that
clearly communicates what went wrong when they fail and are easy to
understand how they failed. So, in this case maybe we should even have
two tests? TestDeprecatedMarkStackFlags and
TestDeprecatedConcGCThreadsFlags.
Instead of parsing the PrintFlagsFinal output you could use
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get the
option values and check if they are set correctly. I think that will
reduce the number of lines in the test further.
Thanks,
Bengt
>
> Thanks!
>
> - Derek
>
> On 11/18/14 11:40 AM, Derek White wrote:
>> Hi Team,
>>
>> First review request. Please let me know if I've forgotten something
>> or have gone completely off the rails.
>>
>> The main point of this bug is to remove deprecated -XX options which
>> are alias for other options.
>>
>> The only complicated part is that one case,
>> /CMSParPromoteBlocksToClaim/ was not a true alias for /OldPLABSize/
>> but a parallel option with different defaults that were synchronized
>> in ergo processing. This fix removes the /CMSParPromoteBlocksToClaim
>> /variable but preserves using different defaults in the CMS case.
>>
>> Also in this fix I added warning messages to several remaining
>> undocumented command line options aliases. This should ease removal
>> of these options in the future
>> CMSMarkStackSize ==> MarkStackSize (MarkStackSize not documented either, but came in jdk6)
>> G1MarkStackSize ==> MarkStackSize
>> CMSMarkStackSizeMax ==> MarkStackSizeMax (MarkStackSizeMax not documented either)
>> ParallelMarkingThreads => ConcGCThreads (ConcGCThreads came in jdk6)
>> ParallelCMSThreads ==> ConcGCThread
>>
>> Thanks,
>> - Derek
>>
>> *Webrev*: http://cr.openjdk.java.net/~drwhite/8061611/webrev.00/
>>
>> *Bug*: https://bugs.openjdk.java.net/browse/JDK-8061611
>>
>> *Testing*:
>> jprt:
>> Saw 1-2 intermittent failures that went away on retesting - hangs
>> and timeouts.
>>
>> refworkload:
>> no differences
>>
>> jtreg: Saw a few unexplained results. Not sure if typical or not:
>>
>>
>> Execution failed: `main' threw exception:
>> java.lang.Exception: jmap -heap exited with error code: 1
>>
>> * gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
>> <http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.jtr>:
>> Checks that jmap -heap contains the flag
>> CompressedClassSpaceSize
>>
>>
>> Program
>> `/export/users/drwhite/test-builds/j2sdk-image.11.17.2014/bin/java'
>> interrupted! (timed out?)
>>
>> * closed/runtime/AppCDS/SharedArchiveConsistency.java
>> <http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/closed/runtime/AppCDS/SharedArchiveConsistency.jtr>:
>> SharedArchiveConsistency
>>
>> Plus a bunch of tests that are labelled "ignored".
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20141215/97a321f6/attachment.htm>
More information about the hotspot-gc-dev
mailing list