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

sangheon.kim sangheon.kim at oracle.com
Wed Aug 26 18:41:44 UTC 2015

Hi Gerard,

On 08/26/2015 11:05 AM, gerard ziemski wrote:
> hi Sangheon,
> If you are still working on the webrev, can you please update 
> account for the new ranges and constraint, so that we avoid 
> dynamically resizing memory at startup?
Oh, you are right.
Thank you for the comment.

I will change them to current actual sizes of 'range=165' and 
These will be included on next webrev.


> 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.

More information about the hotspot-dev mailing list