RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing

[gerard ziemski]

hi Sangheon,

If you are still working on the webrev, can you please update INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE initial 
values to account for the new ranges and constraint, so that we avoid dynamically resizing memory at startup?

If you don't get to it, then that it's OK too - I will make sure they have their values updated in my upcoming webrev.


cheers

On 08/24/2015 04:33 PM, sangheon.kim wrote:
> Hi Kim,
>
> On 08/24/2015 02:16 PM, Kim Barrett wrote:
>> On Aug 24, 2015, at 3:06 PM, sangheon.kim <sangheon.kim at oracle.com> wrote:
>>> Hi Kim,
>>>
>>> Here's webrev.03 which includes your comment for MarkStackSize constraint function.
>>>
>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03
>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/
>>>
>>> And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 .
>> If the value of MarkStackSizeMax were changed later, there's nothing
>> to verify MarkStackSize is still smaller.  [This is related to my
>> earlier comment about constraints between options being tested twice
>> and failures reported twice.]  Do we care in this case?
> If your concern is something like
> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100.
> Yes, in this case the order is important as ranges and constraint functions are verified by its order.
> MarkStackSizeMax will be verified first(its range) and MarkStackSize will be compared with verified MarkStackSizeMax.
>
> And as I said your original concern is current limitation.
> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50),
> they will print out 2 failure messages.
>
> Thanks,
> Sangheon
>
>>
>> Other than that, looks good.
>>
>
>
>