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

[Dmitry Dmitriev]

Jon, thank you for the information!
I think that we can correct minimum value for the flag and see how it 
goes. And if we encounter problem with test again, then we can exclude 
min value.

Dmitry

On 17.02.2016 22:45, Jon Masamitsu wrote:
> 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
>>>>>
>>>>
>>>
>>
>