RFR (S): 8067438: Add test to verify minimal heap size

[Dmitry Fazunenko]

Hi Bengt,

 > https://bugs.openjdk.java.net/browse/JDK-8067768
 > https://bugs.openjdk.java.net/browse/JDK-8067770

Thanks for that! I submitted corresponding RFEs for new tests.

-- Dima

On 17.12.2014 12:15, Bengt Rutisson wrote:
>
> Hi Dima,
>
> On 2014-12-16 15:53, Dmitry Fazunenko wrote:
>> Hi Bengt,
>>
>> I completely agree with your approach.
>> New version of test looks good.
>> It doesn't cover the boundary case of 2m, but 4m is small enough. We 
>> need separate tests for testing boundary values.
>
> Thanks for the review!
>
>> BTW, have you submitted bugs for incorrect interpretation of values?
>
> I wanted to hear your thoughts before I filed the bug reports. Did it 
> now.
>
> https://bugs.openjdk.java.net/browse/JDK-8067768
> https://bugs.openjdk.java.net/browse/JDK-8067770
>
> Thanks,
> Bengt
>
>>
>> Thanks
>> Dima
>>
>>
>>
>>
>> On 16.12.2014 14:16, Bengt Rutisson wrote:
>>>
>>> Hi Dima,
>>>
>>> Thanks for looking at this!
>>>
>>> On 2014-12-15 15:06, Dmitry Fazunenko wrote:
>>>> Hi Bengt,
>>>>
>>>> The test looks good, but summary needs to be updated.
>>>>
>>>>   28  * @summary Verify that the heap gets set up to the expected size
>>>>
>>>> From this summary it's not clear, that the test is for the minimal 
>>>> supported Xmx value.
>>>
>>> Good point. I updated the summary, but I also changed the test a 
>>> bit. See below.
>>
>>>
>>>>
>>>> Would it make more tests to for minimal heap size?
>>>> - setting -Xmx from 1024k to 2047k is equivalent to setting 2m.
>>>> - vm doesn't start if Xmx1023k and less
>>>
>>> You point out a rather strange behavior. The reason the VM does not 
>>> start with 1023K is actually not that we check the maximum heap size 
>>> (Xmx) but that we check the initial heap size (Xms). Xms must be 
>>> larger than 1m otherwise the VM does not start. According to the 
>>> specification of -Xmx it has to be at least 2m:
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>
>>> ...but we don't check that. We just silently increase the heap size 
>>> from 1m to 2m and start the VM if you run with -Xmx1m. I find this 
>>> more of a bug than a feature we want to test. So, I prefer to file a 
>>> bug report against that behavior instead of including this in the test.
>>>
>>> Another interesting aspect is that the max heap size is aligned to 
>>> fill up the memory that is covered by the card table we set up. We 
>>> size the card table to be aligned with the os page size. Each byte 
>>> in the card table corresponds to 512 bytes of heap memory. This 
>>> means that if we have 4K pages, each pages committed for the card 
>>> table corresponds to 2m of heap. But if we have 8K pages one card 
>>> table page will correspond to 4m of heap. Essentially this means 
>>> that the heap is aligned to 2m or 4m based on the minimal os page size.
>>>
>>> On most platforms the minimum page size is 4k but on Sparc it is 8k. 
>>> So, the test I suggested in webrev.00 actually fails on Sparc.
>>>
>>> Again I think this is a strange behavior that I'd rather consider a 
>>> bug than a behavior we want to verify in a test.
>>>
>>> So, my suggestion is to file two bugs for these issues and instead 
>>> of testing the minimum heap size according to the specification I'll 
>>> just test that a small heap works. If I use 4m for the test it 
>>> should work on all our supported platforms. What do you think about 
>>> this approach?
>>>
>>> Here's an updated webrev with a test that uses 4m. Note that the 
>>> test changed its name to TestSmallHeap.
>>>
>>> http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/
>>>
>>> Thanks,
>>> Bengt
>>>
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>>
>>>> On 15.12.2014 16:19, Bengt Rutisson wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Can I have a couple of reviews for this small test to verify that 
>>>>> the VM starts with a minimum heap size of 2mb?
>>>>>
>>>>> http://cr.openjdk.java.net/~brutisso/8067438/webrev.00/
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8067438
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>
>>>
>>
>