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

[Stefan Johansson]

Hi Mikael,

On 2016-09-07 10:46, 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.
>
> 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/
Looks good,
StefanJ

> Bug: https://bugs.openjdk.java.net/browse/JDK-8161079
>
> /Mikael