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

[Bengt Rutisson]

On 2015-01-07 21:35, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2015-01-07 at 21:07 +0100, Bengt Rutisson wrote:
>> On 1/7/15 5:04 PM, Lindenmaier, Goetz wrote:
>>> Hi Bengt,
>>>
>>> I had to add the new path to this line:
>>>    * @library /testlibrary /testlibrary/whitebox  /../../test/lib
>> Right. I was using a repository that hadn't been updated to include this
>> change yet. Good that you noticed it and could handle it.
>>
>>> But then it works fine on the machine with 64K pages.
>> Great to hear! And my testing on our platforms also passed.
> Please add a comment about the 512 magic number in the test, and that we
> assume that the heap constraint of page size * 512 is at this time the
> largest heap sizing constraint. I.e. that this formula is a
> simplification of the actual calculation.
>
> Did you also test on a machine with large pages with parallel gc? Iirc
> there has been some constraint that e.g. parallel gc needs at least
> three (or four?) full pages for its heap, one for each of its spaces.
>
> So I am not sure if this test as is is sufficiently robust.

We don't use large pages for such small heaps. See this in 
Arguments::finalize_vm_init_args():


   if (FLAG_IS_DEFAULT(UseLargePages) &&
       MaxHeapSize < LargePageHeapSizeThreshold) {
     // No need for large granularity pages w/small heaps.
     // Note that large pages are enabled/disabled for both the
     // Java heap and the code cache.
     FLAG_SET_DEFAULT(UseLargePages, false);
   }

LargePageHeapSizeThreshold is 128 MB and since my test runs with -Xmx2m 
(which admittedly can be aligned up to 32 mb) I think we will never use 
large pages.

But I'll do an explicit run on a large page enabled machine with 
ParallelGC just to make sure.

Thanks,
Bengt

>
> Thanks,
>    Thomas
>