RFR: JDK-8086056: ParNew: auto-tune ParGCCardsPerStrideChunk

[Dmitry Dmitriev]

I check and test will pass with following line:
* @run main/othervm -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100 
-XX:DynamicParGCStridesMinSize=1 -XX:DynamicParGCStridesMaxSize=32768 
TestOptionsWithRangesDynamic

Also, Tony, I have few comments about patch:

In src/share/vm/runtime/commandLineFlagConstraintsGC.cpp module:
1) All new 4 constraint functions not add new line when print about error.
2) DynamicParGCStridesMinSizeConstraintFunc print value of 
DynamicParGCStridesMaxOldGenCapacity instead of 
DynamicParGCStridesMaxSize(line 81).
3) DynamicParGCStridesMaxSizeConstraintFunc print value of 
DynamicParGCStridesMinOldGenCapacity instead of 
DynamicParGCStridesMinSize(line 97).

Thanks,
Dmitry


On 06.07.2015 19:18, Dmitry Dmitriev wrote:
> Hi Gerard and Thomas,
>
> Yes, we need special case in this case. In case of dynamic options the 
> simplest way is just add this depenency to the test command line. Test 
> located here:
> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java 
>
>
> If you open it, you can found following line:
>
> * @run main/othervm -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100 
> TestOptionsWithRangesDynamic
>
> So, this line already contains special case for 
> MinHeapFreeRatio/MaxHeapFreeRatio. So, you can add 
> DynamicParGCStridesMaxSize and DynamicParGCStridesMinSize to this 
> command line - add DynamicParGCStridesMinSize=<min_value> and 
> DynamicParGCStridesMaxSize=<max_value>. As I understand the valid 
> range for these flags is range(1, 32*K). Thus, you can chage it to the 
> following:
>
> * @run main/othervm -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100 
> -XX:DynamicParGCStridesMinSize=1 -XX:DynamicParGCStridesMaxSize=32768 
> TestOptionsWithRangesDynamic
>
> Also, I found your JPRT job and I will try to test this approach. And 
> I will think how test for manageable options with dependecies can be 
> improved.
>
> Thank you,
> Dmitry
>
>
> On 06.07.2015 18:16, Gerard Ziemski wrote:
>> hiThomas,
>>
>> On 7/6/2015 6:51 AM, Thomas Schatzl wrote:
>>> Hi Gerard,
>>>
>>> On Fri, 2015-06-26 at 09:26 -0500, Gerard Ziemski wrote:
>>>> hi guys,
>>>>
>>>> On 6/26/2015 8:30 AM, Tony Printezis wrote:
>>>>> The JEP says:
>>>>>
>>>>> "The range and constraints checks are done every time a flag changes,
>>>>> as well as late in the JVM initialization routine (i.e., in
>>>>> init_globals() after stubRoutines_init2()) at the time when all flags
>>>>> have their final values set. We will continue to check the manageable
>>>>> flags as long as the JVM runs."
>>>>>
>>>>> I haven't actively been using this myself, but I assume that the
>>>>> constraints will be checked every time a managaeble flag is changed
>>>>> and that the one trying to change it will get an error reported back
>>>>> if they try to change it in an invalid way.
>>>> The JEP required that in the case of manageable flags, when an attempt
>>>> is made to change value of a flag from outside the Java process, 
>>>> that an
>>>> error message be printed in the outside process and the value be left
>>>> unchanaged.
>>>>
>>>> If the Java process itself tries to make such change, however, then 
>>>> the
>>>> error message is printed in the process itself and the VM exits.
>>>>
>>>> There is a window of time, however, during the initialization process,
>>>> when flags are being still set, so during that time the 
>>>> range/constraint
>>>> check is disabled, but changes after Arguments::apply_ergo() are fatal
>>>> to the VM if check fails.
>>>    currently looking at some failures in the 
>>> TestOptionsWithRangesDynamic
>>> jtreg test. The test seems to fail because it tries to set the various
>>> options independently of the options it depends on (in the constraint
>>> functions).
>>>
>>> E.g. sets DynamicParGCStridesMaxSize to 1, which then fails ("Can not
>>> change option to avlid value "1" via jcmd") because of "value violates
>>> its flags constraints" which include DynamicParGCStridesMinSize, which
>>> default value is 256, making the max size < min size.
>>>
>>> What is the recommened way to fix this problem?
>>
>> Good question.
>>
>> I'm including Dmitry, who wrote the testing framework.
>>
>> Dmitry: do we need special cases in the JTREG test for those flags 
>> that have constraints that further limit the available range beyond 
>> that of its defined range?Should Thomas jump into the JTREG test code 
>> and do this himself? Can you give him some pointers on how and where 
>> to insert such additional logic?
>>
>> The JEP has specifically said that we were not allowed to 
>> automatically change a flag's value that violated the range or 
>> constraint, even though for ranges it would have been trivial to do 
>> so, and even for constraints quite doable. If we were allowed to do 
>> that, then this issue wouldn't exist.
>>
>>
>> cheers
>>
>>
>