RFR (S): 8079208: gc/g1/TestLargePageUseForAuxMemory.java fails due to not considering page allocation granularity for setup
jon.masamitsu at oracle.com
Thu May 14 17:44:27 UTC 2015
On 05/13/2015 03:17 PM, Thomas Schatzl wrote:
> On Wed, 2015-05-13 at 14:50 -0700, Jon Masamitsu wrote:
>> On 5/13/2015 8:03 AM, 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
>> Is there a change for this need to run the test with sufficient privileges?
> There is no way I know of to specify the requirement of this privilege
> anywhere in jprt. Any idea?
> In other test frameworks you could require large-page support for the
>>> 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.
>> The fix to the test looks good.
>> Is it important to the test that the amount subtracted be the minimum
>> needed to disable large pages? I mean, is the test less useful if
>> twice that minimum was subtracted?
> It will not test that the expected cross-over between using large pages
> and small pages is at exactly at that particular heap size. This seems
> to test more than when subtracting any random value.
Yes, the test would not test the exact cross-over
but it would be close and would be conservative
enough to avoid things like rounding differences.
Please leave it as it.
> However I can add this test case too.
No need to add that case.
>>> 119 final long heapSizeDiffForCardTable = Math.max(Math.max(allocGranularity * cardSize, HEAP_REGION_SIZE), largePageSize);
>> would this description be correct?
>> // Minimum change in heap size that will disable large pages for the
>> card table if subtracted from
>> // the heap size. Increasing the heap by this amount should not change
>> the use of large pages
>> // for the card table.
>> If yes, would you mind adding it.
> Will do, thanks.
More information about the hotspot-gc-dev