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

[Bengt Rutisson]

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
>>>
>>
>