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

Bengt Rutisson bengt.rutisson at oracle.com
Thu Jan 8 07:44:03 UTC 2015

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 

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

More information about the hotspot-gc-dev mailing list