RFR: 8281472: JVM options processing silently truncates large illegal options values

[Ioi Lam]

On Fri, 18 Feb 2022 13:47:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Test test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java has the following code:
>> 
>> 
>>     // 4294967295 == (unsigned int) -1
>>     // So setting ParallelGCThreads=4294967295 should give back 4294967295
>>     // and setting ParallelGCThreads=4294967296 should give back 0. (SerialGC is ok with ParallelGCThreads=0)
>>     for (long i = 4294967295L; i <= 4294967296L; i++) {
>>       long count = getParallelGCThreadCount(
>>           "-XX:+UseSerialGC",
>>           "-XX:ParallelGCThreads=" + i,
>>           "-XX:+PrintFlagsFinal",
>>           "-version");
>>       Asserts.assertEQ(count, i % 4294967296L, "Specifying ParallelGCThreads=" + i + " does not set the thread count properly!");
>>     }
>>   }
>
> That test seems bizarre to me - perhaps someone from GC team can comment on why it expects to see what it sees. But I would not suggest we cripple the argument processing logic just because one test expects it to behave in a strange way.

Setting ParallelGCThreads=4294967296 isn't a reasonable real-life use case. There's no need to check for the JVM's behavior under this situation (which now becomes illegal).

There's already a test for  "SerialGC is ok with ParallelGCThreads=0" on line 100 of this file. So the block quoted by Harold should be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7522