RFR(S) 8161079: Default heap size causes native memory exhaustion on 32 bit Windows

[Thomas Schatzl]

Hi Mikael,

On Wed, 2016-09-07 at 10:46 +0200, Mikael Gerdin wrote:
> Hi all,
> 
> Please review this small change intended to bound the default heap 
> sizing ergonomics on the 32 bit Windows JVM.
> The default heap sizing is based on a combination of the MaxRAM and 
> MaxRAMFraction flags where the default values end up sizing the heap
> to roughly a quarter of available memory. The problem is that on
> Windows we don't account for the fact that the amount of available
> address space for a 32 bit process is only 2G and in some cases even
> less due to dlls linked into fixed addresses in all processes (hello
> HydraDMH.dll)
> 
> My suggested fix is to attempt to work around this problem by
> bounding the MaxRAM value by ullTotalVirtual as returned by the win32
> call GlobalMemoryStatusEx().
> 
> Performance testing shows a 7-8% throughput reduction but hopefully
> we will see less occurrences of native memory exhaustion as a result.

You mean, for 32 bit windows only? Is this compared to earlier -client
runs (which had been the default in 8 iirc), or -server ones?

> The reason for this problem not surfacing earlier appears to be a 
> combination of:
> * -client has been the default on 32 bit Windows and has even further
> bounded heap sizing
> * generally more cores in machines in combination with tiered 
> compilation and the G1 garbage collector leads to more memory usage
> by 
> thread stacks
> 
> Webrev: http://cr.openjdk.java.net/~mgerdin/8161079/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161079

  looks good.

Thomas