RFR(s): 8145312: CMS: There is insufficient memory with CMSSamplingGrain=1
sangheon
sangheon.kim at oracle.com
Wed Mar 9 19:50:27 UTC 2016
Hi Dmitry,
Thanks for reviewing this.
I will include the flag before I push it.
Sangheon
On 03/09/2016 12:39 AM, Dmitry Dmitriev wrote:
> 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