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

[Mikael Gerdin]

Hi Thomas,

On 2016-09-07 10:54, Thomas Schatzl wrote:
> 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?

Thanks for asking for clarification here, here's a short summary of the 
results:

My MaxRAM -server VM regresses 7-8% compared to -server without a 
bounded MaxRAM. Essentially the comparision is
-server -XX:MaxRAM=2G (which is what my fix ends up doing) vs
-server -XX:MaxRAM=4G (which is the default value on 32 bit otherwise)

Compared to -client my MaxRAM -server VM is still around 900% faster.

The regression only affects 32 bit Windows.


>
>> 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.

Thanks

/Mikael

>
> Thomas
>