RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing

[sangheon.kim]

Hi Gerard,

Thank you for looking at this.

On 09/11/2015 11:13 AM, gerard ziemski wrote:
> hi Sangheon,
>
> #1 test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
>
> Please change the comment to:
>
> +        /*
> +         * Exclude below options as their maximum value would consume 
> too much memory
> +         * and would affect other tests that run in parallel.
> +         */
Okay, I will fix as you suggested.

>
>
> #2 What tests did you run? Did you run 
> test/runtime/CommandLine/OptionsValidation on all platforms (including 
> embedded)?
No.
I ran tests under test/runtime/CommandLine/OptionsValidation (especially 
TestOptionsWithRanges.java) for all platforms except embedded.
Let me back after testing on embedded.

Thanks,
Sangheon


>
>
> cheers
>
>
> On 09/10/2015 07:01 PM, sangheon.kim wrote:
>> Hi all,
>>
>> Please review this patch for command-line validation for GC flags.
>> This REDO patch is adding ranges and implementing constraint 
>> functions for GC flags.
>>
>> Original CR of JDK-8078555 was backout as it made a test failure from 
>> 'TestOptionsWithRanges.java'.
>> And also there were some discussion of OOM handling.
>>
>> Most parts are same as JDK-8078555 except below:
>> 1. Changed 'range' for some flags.
>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. These flags 
>> make this test unstable as it tries to allocate
>> huge amount of memory.
>>
>> And below are the suggestion note for JDK-8078555:
>> 1. Exponential notation for 'double' type variable parse: Previously 
>> there were some discussion for maximum value for
>> double type flags from code review of JDK-8059557 and JDK-8112746. 
>> And Kim and I decided not to add upper limit unless
>> there are problems with DBL_MAX. And as 255 is the maximum length 
>> that can be passed via command-line, we introduced
>> exponential notation to avoid this limit. ( arguments.cpp )
>> 2. These GC flags ranges are not ideal ranges but ranges which don't 
>> make problem with current source code.
>>      If one flag makes some problem but hard to find good range, I 
>> added some ranges.
>> 3. There are some constraint functions to avoid overflow.
>> 4. Test applications are changed: as some of them assumed to be 
>> ParallelGC or to check it's output messages.
>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8134995
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/
>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555
>>
>> Testing:
>> JPRT, UTE(vm.quick-pcl) and 
>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
>>
>> Thanks,
>> Sangheon
>>
>>