RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments"
David Holmes
david.holmes at oracle.com
Wed May 27 01:18:58 UTC 2015
Hi Dmitry,
Just browsing through ...
test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
60 if (name.startsWith("CMS")) {
61 option.addPrepend("-XX:+UseConcMarkSweepGC");
62 }
Not all CMS related options start with CMS. Is this just looking for the
particular subset of options that do start with CMS? Is starting with
CMS or starting with G1 significant with regards to the type of option?
64 switch (name) {
65 case "MinHeapFreeRatio":
66 option.addPrepend("-XX:MaxHeapFreeRatio=100");
67 break;
68 case "MaxHeapFreeRatio":
69 option.addPrepend("-XX:MinHeapFreeRatio=0");
70 break;
It isn't at all clear why these options have to have special treatment,
or how the prepended option relates to the option under test?
106 static private void addTypeDependency(JVMOption option, String
type) {
107 if (type.contains("C1") || type.contains("C2")) {
108 /* Run in compiler mode for compiler flags */
109 option.addPrepend("-Xcomp");
110 }
111 }
Don't you need to ensure -client or -server to deal with C1 and C2 options?
---
test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
58 * Is this value is signed or unsigned
63 * Is this value is 64 bit unsigned
delete 'is'
I'm confused by the MIN_LONG/MAX_LONG etc variables. Are these supposed
to be representing C-types? We don't use C "long" as a rule.
Also unclear why you need to use BigInteger here instead of just Java
long for everything ??
---
test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/DoubleJVMOption.java
31 private final double MAX_DOUBLE = 18446744073709551616.000;
where does this magic number come from? (And why 3 zeroes after the
decimal point ??)
Thanks,
David
On 22/05/2015 6:57 AM, Dmitry Dmitriev wrote:
> Hello all,
>
> Recently I correct several typos, so here a new webrev for tests:
> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/
> <http://cr.openjdk.java.net/%7Eddmitriev/8059557/webrev.02/>
>
> Thanks,
> Dmitry
>
> On 18.05.2015 18:48, Dmitry Dmitriev wrote:
>> Hello all,
>>
>> Please review test set for verifying functionality implemented by JEP
>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review
>> request for this JEP can be found there:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html
>>
>> I create 3 tests for verifying options with ranges. The tests mostly
>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this
>> file contains functions to get options with ranges as list(by parsing
>> new option "-XX:+PrintFlagsRanges" output), run command line test for
>> list of options and other. The actual test code contained in
>> common/optionsvalidation/JVMOption.java file - testCommandLine(),
>> testDynamic(), testJcmd() and testAttach() methods.
>> common/optionsvalidation/IntJVMOption.java and
>> common/optionsvalidation/DoubleJVMOption.java source files contain
>> classes derived from JVMOption class for integer and double JVM
>> options correspondingly.
>>
>> Here are description of the tests:
>> 1)
>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
>>
>>
>> This test get all options with ranges by parsing output of new option
>> "-XX:+PrintFlagsRanges" and verify these options by starting Java and
>> passing options in command line with valid and invalid values.
>> Currently it verifies about 106 options which have ranges.
>> Invalid values are values which out-of-range. In test used values
>> "min-1" and "max+1".In this case Java should always exit with code 1
>> and print error message about out-of-range value(with one exception,
>> if option is unsigned and passing negative value, then out-of-range
>> error message is not printed because error occurred earlier).
>> Valid values are values in range, e.g. min&max and also several
>> additional values. In this case Java should successfully exit(exit
>> code 0) or exit with error code 1 for other reasons(low memory with
>> certain option value etc.). In any case for values in range Java
>> should not print messages about out of range value.
>> In any case Java should not crash.
>> This test excluded from JPRT because it takes long time to execute and
>> also fails - some options with value in valid range cause Java to
>> crash(bugs are submitted).
>>
>> 2)
>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
>>
>>
>> This test get all writeable options with ranges by parsing output of
>> new option "-XX:+PrintFlagsRanges" and verify these options by
>> dynamically changing it's values to the valid and invalid values. Used
>> 3 methods for that: DynamicVMOption isValidValue and isInvalidValue
>> methods, Jcmd and by attach method. Currently 3 writeable options with
>> ranges are verified by this test.
>> This test pass in JPRT.
>>
>> 3) hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java
>>
>> This test verified output of Jcmd when out-of-range value is set to
>> the writeable option or value violates option constraint. Also this
>> test verify that jcmd not write error message to the target process.
>> This test pass in JPRT.
>>
>>
>> I am not write special tests for constraints for this JEP because
>> there are exist test for that(e.g.
>> test/runtime/CompressedOops/ObjectAlignment.java for
>> ObjectAlignmentInBytes or
>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for
>> MinHeapFreeRatio/MaxHeapFreeRatio).
>>
>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8059557/webrev.00/>
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557
>>
>> Thanks,
>> Dmitry
>>
>
More information about the hotspot-dev
mailing list