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

[Gerard Ziemski]

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