RFR(XXS): 8145312: [TESTBUG] CMS: unable to create: There is insufficient memory

Jon Masamitsu jon.masamitsu at oracle.com
Wed Feb 17 19:45:22 UTC 2016


Dmitry,

I think the fix using the large minimum value should
be tried but should warn you that as  the heap scales
to larger and larger values, the test will
eventually fail even with the change of minimum value of
CMSSamplingGrain.  The problem is that the GC allocates
an array whose size scales with the heap size (proportional to
heap-size / CMSSamplingGrain).  So with large enough heap
sizes, I think it is still possible that this test will fail.  It might
not fail with the default heap size (1/4 of the physical memory
size so that the array size) though.

I added comments to the CR explaining this.

Jon

On 2/17/2016 11:02 AM, Dmitry Dmitriev wrote:
> Thank you for exploration! I vote for fixing the minimum value instead 
> of excluding minimum value from the test. Can you please add this 
> information as a comment to the JDK-8145312? Thank you!
>
> Dmitry
>
> On 17.02.2016 21:49, Jon Masamitsu wrote:
>>
>>
>> On 2/17/2016 10:06 AM, Dmitry Dmitriev wrote:
>>> Hello Jon,
>>>
>>> Thank you for the review&suggestion! Please, see my comment inline.
>>>
>>> On 17.02.2016 20:47, Jon Masamitsu wrote:
>>>> Dmitry,
>>>>
>>>> Change looks good.
>>>>
>>>> The minimum size of CMSSamplingGrain should be the minimum object
>>>> size (in bytes) instead of 1.   Would that allow the test to pass?
>>> I think yes, test will not hit OOM for bigger minimum value. As 
>>> Joseph wrote in the bug comment: "
>>> Is this a valid argument: -XX:CMSSamplingGrain=1? Default is 16K and 
>>> it succeeds.
>>> If I use 1K it doesn't fail.
>> -XX:CMSSamplingGrain=1 is not valid in this context.  The code that 
>> uses it is trying to calculate
>> points at which the young gen should be partitioned for doing 
>> parallel work.  It only makes
>> sense to partition at a granularity equal to or larger than the 
>> object size.  Minimum value should be 8 which corresponds to the 
>> minimum object size on 32bit.    It would be OK to use the same on a 
>> 64bit system
>> for simplicity.
>>
>>>
>>> In fact it doesn't fail with the value 2.
>>>
>>> eden_chunk_capacity = (young_gen->max_capacity() + CMSSamplingGrain) 
>>> / CMSSamplingGrain;
>>>     eden_chunk_array = NEW_C_HEAP_ARRAY(HeapWord*, 
>>> eden_chunk_capacity, mtGC);
>>>
>>> with 2, there's just enough c heap. "
>>>
>>> Probably, we can consider changing of the minimum value for this flag?
>>
>> Yes, the minimum value should be changed.
>>
>> Jon
>>>
>>> Thank you,
>>> Dmitry
>>>
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 2/12/2016 12:04 PM, Dmitry Dmitriev wrote:
>>>>> Hello,
>>>>>
>>>>> Please, review small fix to the TestOptionsWithRanges test to 
>>>>> exclude testing of min value for CMSSamplingGrain option, because 
>>>>> this can cause OOM error.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145312
>>>>> webrev.00: 
>>>>> http://cr.openjdk.java.net/~ddmitriev/8145312/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eddmitriev/8145312/webrev.00/>
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>
>>>
>>
>



More information about the hotspot-gc-dev mailing list