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

[Thomas Schatzl]

Hi,

On Fri, 2018-01-19 at 15:11 +0000, stewartd.qdt wrote:
> Yes, I too wondered if the test should be changed to be a bit more
> discerning in how it operates. 
> 
> I agree it would be great if a member of the GC team could chime in
> on this issue. 
> 
> Daniel
> 
> -----Original Message-----
> 
> > 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"?
> 
> Hopefully one of the GC folk will chime in.

The test has obviously been written with existing test setups we have
that are configured accordingly.

I think for the test it may be sufficient to simply remove the -Xms
flags in the VM invocations. Then the test would not try to actually
commit all of the pages for e.g. the heap.

That assumes it is no problem for these systems to only reserve 512G,
and the systems themselves, if configured to use 1g huge pages is
configured properly, i.e. there are actually have a few gb of memory
available (unless -version does not even create objects on the java
heap).

Otherwise, instead of adding a new whitebox method, it might be
preferable to get free/physical memory using standard Java means like
OperatingSystemMXBean [1].

Thanks,
  Thomas

[1] https://docs.oracle.com/javase/9/docs/api/com/sun/management/Operat
ingSystemMXBean.html