RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments"
Gerard Ziemski
gerard.ziemski at oracle.com
Wed May 27 18:19:58 UTC 2015
Nice code Dmitry!
I have a bit of feedback, but I might be off on some of them, and some reflect my personal preference:
1.http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java.html
1 a.
Line 27, from: "value which not allowd by constraint. Also check that”
to: "value which is not allowed by constraint. Also check that”
1 b.
Line 28, from: "jcmd not print error message to the target process output.”
to: "jcmd does not print an error message to the target process output."
1 c.
Line 49, from: "System.out.println("Verify jcmd error message and that jcmd not write errors to the target process output");”
to: "System.out.println(“Verify jcmd error message and that jcmd does not write errors to the target process output");”
1 d.
Line 67: "67 Asserts.assertGT(minHeapFreeRatio, 0, "MinHeapFreeRatio must be greater than 0”);”
Shouldn’t that be "Asserts.assertGTOE (>=)", not “Asserts.assertGT”?
1 e.
Line 68: “Asserts.assertLT(maxHeapFreeRatio, 100, "MaxHeapFreeRatio must be less than 100");”
Shouldn’t that be "Asserts.assertLTOE (<=)", not “ Asserts.assertLT”?
2.http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/DoubleJVMOption.java.html
2 a.
Line 31: "private final double MAX_DOUBLE = 18446744073709551616.000;”
Just curious: why can’t we use Double.MAX_VALUE? where does your value come from?
2 b.
Line 126, from : "if (min == Double.MIN_VALUE && max == MAX_DOUBLE) {“
to : "if ((Double.equal(min, Double.MIN_VALUE) == 0) && (Double.equal(max, MAX_DOUBLE) == 0)) {“
2 c.
Line 127: "validValues.add(String.format("%f", -1.5));”
Line 129: validValues.add(String.format("%f", 0.85));
Just curious: why did you pick -1.5 and 0.85? I personally would have selected min/2.0 and max/2.0 and maybe -1.0 and 1.0
2 d.
We need to change from:
145 if (min != Double.MIN_VALUE) {
146 invalidValues.add(String.format("%f", min - 0.01));
147 }
148
149 if (max != MAX_DOUBLE) {
150 invalidValues.add(String.format("%f", max + 0.01));
151 }
to:
145 if ((Double.equal(min, Double.MIN_VALUE) != 0) && (Double.isNaN(min-0.01) == false)) {
146 invalidValues.add(String.format("%f", min - 0.01));
147 }
148
149 if ((Double.equal(max, MAX_DOUBLE) != 0) && (Double.isNaN(max+0.01) == false)) {
150 invalidValues.add(String.format("%f", max + 0.01));
151 }
3.http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java.html
3 a.
Line 331, from : * @param valid Indicates, should JVM failed or not
to : * @param valid Indicates whether the JVM should fail or not
3 b.
Line 361, from : } else if (returnCode == 1 && out.getOutput().isEmpty()) {
to : } else if ((returnCode == 1) && (out.getOutput().isEmpty() == true)) {
4.http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java.html
4 a.
125 static private Map<String, JVMOption> getJVMOptions(Reader inputReader,
126 boolean withRanges, Predicate<String> acceptOrigin) throws IOException {
I see that the implementation uses hardcoded positions, ex. "line.substring(0, 9)” Would it be hard to make the code character position independent by considering an implementation based on a “grep” or some other pattern recognition? If we ever tweak the output in ranges printout, even ever so slightly, this code will need to be updated.
cheers
> On May 26, 2015, at 1:24 PM, Gerard Ziemski<gerard.ziemski at oracle.com> wrote:
>
>
>
>
> -------- Forwarded Message --------
> Subject: Re: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments"
> Date: Thu, 21 May 2015 23:57:11 +0300
> From: Dmitry Dmitriev<dmitry.dmitriev at oracle.com>
> Organization: Oracle Corporation
> To: hotspot-dev at openjdk.java.net, Gerard Ziemski<gerard.ziemski at oracle.com>
>
> Hello all,
>
> Recently I correct several typos, so here a new webrev for tests:http://cr.openjdk.java.net/~ddmitriev/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/
>>
>> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557
>>
>> Thanks,
>> Dmitry
>>
>
More information about the hotspot-dev
mailing list