RFR(S) 8161079: Default heap size causes native memory exhaustion on 32 bit Windows
thomas.schatzl at oracle.com
Wed Sep 7 08:54:29 UTC 2016
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
> 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
> thread stacks
> Webrev: http://cr.openjdk.java.net/~mgerdin/8161079/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161079
More information about the hotspot-gc-dev