RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java

Thomas Stüfe thomas.stuefe at gmail.com
Wed Jan 24 13:00:25 UTC 2018


On Wed, Jan 17, 2018 at 11:43 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Daniel,
>
> On 18/01/2018 3:41 AM, stewartd.qdt wrote:
>
>> Please review this webrev [1] which attempts to fix a test error in
>> gc/g1/TestLargePageUseForAuxMemory when it is run on a machine with 64K
>> pages. See the bug report [2] for further details of why the error occurs.
>> Essentially the test tries to allocate 512 times the huge page size and
>> fails when the huge page size is around ½ - 1 GB is size, because there
>> simply isn't enough physical memory in the system.
>>
>>
>> This fix adds a function to WhiteBox to get the physical memory and then
>> uses that to ensure we are not trying to allocate more than the physical
>> amount of memory for our heap. Please let me know if this is a bad approach
>> and I'll be happy to change as required.
>>
>
> This seems an improvement though I would expect the test to fail long
> before we get close to the amount of physical memory available. Should the
> test be adjusting what it does based on the page size being used, in
> conjunction with the amount of "physical memory"?
>
>
I am not even sure os::physical_memory() would be meaningful on Linux with
huge pages.

Would the real limiting factor not be the size of the huge page pool
(vm.nr_hugepages) ? If that one is too small, or the user has no access
rights to the pool, you would get huge page allocation errors regardless
what physical memory is in the system, no?

Kind Regards, Thomas

Hopefully one of the GC folk will chime in.
>
> Thanks,
> David
>
>
>
>>
>> Thanks,
>>
>> Daniel Stewart
>>
>>
>> [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/
>> [2] - https://bugs.openjdk.java.net/browse/JDK-8195621
>>
>>


More information about the hotspot-dev mailing list