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

[Bengt Rutisson]

Hi Goetz,

On 2015-01-08 09:34, Lindenmaier, Goetz wrote:
> Hi,
>
> I guess if you start setting flags on the command line for tests, many tests
> will break ... What if you set -Xmx4g or -XX:MaxHeapSize etc?

You are right, of course. But unfortunately our internal testing 
framework actually sometimes pass extra arguments to tests. So, for some 
cases we need to be prepared to handle it.

But in this case it turns out that it is not a problem. We actually 
never use large pages for the card table. The page size for the card 
table is always initialized with a small page size:

CardTableModRefBS::CardTableModRefBS()
   ...
   _page_size(os::vm_page_size()),


So, there is actually no need to add -XX:-UseLargePages on the command 
line. I've verified this on a Solaris/Sparc machine with large pages 
enabled. Been running both ParallelGC and G1 with UseLargePages as 
default (true) and with explicitly enabled large pages. For all four 
cases we get a 4m heap if we use -Xmx2m since we pick 8k pages for the 
card table.

Preparing the webrev now...

Bengt

>
> The problem with this test is the default page size.
>
> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com]
> Sent: Donnerstag, 8. Januar 2015 09:17
> To: Thomas Schatzl
> Cc: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR (S): 8067438: Add test to verify minimal heap size
>
>
> On 2015-01-08 09:09, Thomas Schatzl wrote:
>> Hi,
>>
>> On Thu, 2015-01-08 at 08:44 +0100, Bengt Rutisson wrote:
>>> 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.
>> Okay :) But what if somebody sets -XX:+UseLargePages intentionally for a
>> test run?
>>
>> Potentially we will need to exclude this case then.
> Right. Maybe the easiest thing it to just add -XX:-UseLargePages to the
> @run command line. That overrides any arguments passed from JTreg.
>
> Bengt
>
>> Thanks,
>>     Thomas
>>
>>