RFR (S): 8079208: gc/g1/TestLargePageUseForAuxMemory.java fails due to not considering page allocation granularity for setup

[Dmitry Fazunenko]

Hi Thomas,

The fix looks good.
But I would like to ask you about minor improvement: provide more debug 
info. Having values returned by wb methods in the jtr file will be useful.

Another thing I would ask you to do is to distinguish somehow testVM() 
runs. After adding @ignore tag the line numbers were changed, so it's 
not easy to restore from the stack trace which particular testVM call 
caused the failure.
Possible ways to do this:
- print out the values of the parameters given
- add a string parameter to describe expected behavior:

   void testVM(String what, ...) {
       System.out.println(what);
       ...
   }

   testVM("case1: ...", ...);
   testVM("case2: ...", ...);

The second way requires a bit more effort, but it will make logic of 
this complicated test cleaner.

Thanks,
Dima

On 13.05.2015 18:03, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following test fix: the problem is that
> during test setup, when trying to find the heap size where large pages
> are just not used, the code subtracts a fixed value from the one known
> to use large pages for the card table.
>
> The problem is that this fixed value is too small to have an impact on
> the actual size of the card table, i.e. the code rounds up by the OS'es
> allocation granularity. That causes it to use the same size as before,
> where it will then use large pages anyway and fail the test.
>
> That fixed value has been just large enough to cover regular page size.
>
> Also, the only OS that has different allocation granularities and
> (small) page sizes is Windows. Further on Windows, large pages (and the
> test is only executed then) are only available when the user runs as
> Administrator (or has the corresponding capability to lock pages in
> memory).
>
> In this case the test fails.
>
> The change fixes this by making sure that this value to subtract from
> the original heap size is exactly the size that avoids this rounding.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8079208
>
> Webrevs:
> http://cr.openjdk.java.net/~tschatzl/8079208/webrev/ (for hotspot
> changes)
> http://cr.openjdk.java.net/~tschatzl/8079208/webrev.hs-gc/ (for changes
> in the hs-gc directory, i.e. whitebox.java)
>
> Testing:
> Manual testing, jprt
>
> Thanks,
>    Thomas
>
>