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

Dmitry Dmitriev dmitry.dmitriev at oracle.com
Mon Jul 6 16:18:19 UTC 2015

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:

If you open it, you can found following line:

* @run main/othervm -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100 

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 

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 

Thank you,

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

More information about the hotspot-gc-dev mailing list