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

[Mikael Gerdin]

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.

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

/Mikael