RFR(s): 8145312: CMS: There is insufficient memory with CMSSamplingGrain=1

Dmitry Dmitriev dmitry.dmitriev at oracle.com
Wed Mar 9 08:39:04 UTC 2016


Hi Sangheon,

On 09.03.2016 0:40, sangheon wrote:
> Hi Dmitry,
>
> I'm okay with including the flag.
Thank you! Not need a new webrev for that!
>
> Do you mean valid additional big values will be excluded as well?
> I guess max_jint+1 and max_juint+1, right?
Yes, you are right!

Thanks,
Dmitry
>
> I excluded it as it will always fail with its max value and it also 
> tries allocation which would make the testing time longer.
>
> Thanks,
> Sangheon
>
>
> On 03/08/2016 12:26 PM, Dmitry Dmitriev wrote:
>> Hi Sangheon,
>>
>> Please, don't exclude testing of max range for CMSSamplingGrain flag, 
>> because in this case additional big values will be excluded too. Max 
>> value for CMSSamplingGrain will violates constraint, but it's ok for 
>> testing.
>>
>> Thank you,
>> Dmitry
>>
>> On 08.03.2016 11:00, sangheon wrote:
>>> Hi all,
>>>
>>> Could I have some reviews for CMSSamplingGrain flag?
>>>
>>> The flag is used to calculate points at which the young gen should 
>>> be partitioned for doing parallel work, so it only makes sense to 
>>> partition at a granularity equal to or larger than the object size.
>>>
>>> I am proposing to change the minimum value of CMSSamplingGrain from 
>>> '1' to 'ObjectAlignmentInBytes'.  (ObjectAlignmentInBytes has a 
>>> range of [8, 256]).
>>>
>>> In addition, I added a constraint function to avoid an arithmetic 
>>> overflow by its maximum value.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145312
>>> Webrev: http://cr.openjdk.java.net/~sangheki/8145312/webrev.00/
>>> Testing: JPRT, RBT for all platforms including embedded
>>>
>>> Thanks,
>>> Sangheon
>>
>




More information about the hotspot-gc-dev mailing list