JDK-8161079 : Default heap size causes native memory exhaustion on 32 bit Windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-07-08
  • Updated: 2017-07-26
  • Resolved: 2016-09-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b137Fixed
Related Reports
Relates :  
JDK-8166002 - Emulate client build on platforms with reduced virtual address space
Description
Use the 32 bit windows fastdebug build from a current promoted build
(eg b126 as used here) to run the standard SwingSet2 demo

Click around in a couple of tabs and BOOM.
It will die with an error message that amounts to insufficient memory.

C:b126dbg\jdk-9\fastdebug\bin\java -jar SwingSet2.jar
java.lang.OutOfMemoryError
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 566080 bytes for Chunk::n
ew
# An error report file with more information is saved as:
# demo\jfc\SwingSet2\hs_err_pid5036.log
#
# Compiler replay data is saved as:
# demo\jfc\SwingSet2\replay_pid5036.log

This appears to be a regression from removing the client VM as builds
pre-dating that work fine.

I expect that this means that the 32 bit VM product build is also more
likely to run out of memory in the same way - although it will take
more than this demo to do it
Comments
I did an experiment with setting the default value of MaxRAM to the total virtual address space of the process in the os init code. Since the heap setup code selects the minimum of os::physical_memory() and MaxRAM and divides the result by MaxRAMFraction this will in general cause smaller heap sizes on 32 bit and a ~7% regression in for example jbb2005 throughput.
22-07-2016
The default heap sizing is by default 1/4 of the available memory. The problem is that the code queries os::physical_memory() and divides that with MaxRamFraction (=4) In the case of 32 bit Windows the virtual address space can be much smaller than what GlobalMemoryStatus() returns in ullTotalPhys and we go ahead and size the heap way too large. Perhaps it would make sense to use MIN2(avail_phys, avail_virt) to size the heap instead?
20-07-2016
Heap size ergonomics when running java -version: Client: [0.014s][debug][gc,heap] Minimum heap 6291456 Initial heap 16777216 Maximum heap 268435456 [0.031s][info ][gc ] Using Serial java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+110) Java HotSpot(TM) Client VM (build 9-ea+110, mixed mode) --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal Free 66 0`67f25000 ( 1.624 GB) 81.21% <unknown> 31 0`127bb000 ( 295.730 MB) 76.85% 14.44% Image 233 0`0301a000 ( 48.102 MB) 12.50% 2.35% MappedFile 18 0`019fd000 ( 25.988 MB) 6.75% 1.27% Stack32 53 0`004b0000 ( 4.688 MB) 1.22% 0.23% Heap32 19 0`00476000 ( 4.461 MB) 1.16% 0.22% Stack64 45 0`003c0000 ( 3.750 MB) 0.97% 0.18% Other 7 0`001c5000 ( 1.770 MB) 0.46% 0.09% Heap64 3 0`0001f000 ( 124.000 kB) 0.03% 0.01% TEB64 15 0`0001e000 ( 120.000 kB) 0.03% 0.01% TEB32 15 0`0000f000 ( 60.000 kB) 0.02% 0.00% PEB64 1 0`00001000 ( 4.000 kB) 0.00% 0.00% PEB32 1 0`00001000 ( 4.000 kB) 0.00% 0.00% Server: [0.014s][info][gc,heap] Heap region size: 1M [0.018s][debug][gc,heap] Minimum heap 6291456 Initial heap 67108864 Maximum heap 734003200 [0.030s][info ][gc ] Using G1 java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+127) Java HotSpot(TM) Server VM (build 9-ea+127, mixed mode) --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal <unknown> 44 0`3cf9e000 ( 975.617 MB) 88.78% 47.64% Free 66 0`3b500000 ( 949.000 MB) 46.34% Image 233 0`03307000 ( 51.027 MB) 4.64% 2.49% MappedFile 16 0`01ccb000 ( 28.793 MB) 2.62% 1.41% Stack32 183 0`011d0000 ( 17.813 MB) 1.62% 0.87% Stack64 171 0`00e40000 ( 14.250 MB) 1.30% 0.70% Heap32 10 0`008df000 ( 8.871 MB) 0.81% 0.43% Other 7 0`001c5000 ( 1.770 MB) 0.16% 0.09% TEB64 57 0`00072000 ( 456.000 kB) 0.04% 0.02% TEB32 57 0`00039000 ( 228.000 kB) 0.02% 0.01% Heap64 3 0`0001f000 ( 124.000 kB) 0.01% 0.01% PEB64 1 0`00001000 ( 4.000 kB) 0.00% 0.00% PEB32 1 0`00001000 ( 4.000 kB) 0.00% 0.00% When the default heap size setting for server is to use a third of the available process space, I'm not surprised that we run into issues.
20-07-2016
On the other hand, if C2's peak memory usage regularly hits the OOM ceiling then perhaps there needs to be a "soft limit" for compile arena allocations such that a compilation is aborted if its memory usage grows too large.
19-07-2016
Decoded stack trace: --------------- T H R E A D --------------- Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x8dfd29] ?report_and_die@VMError@@SAXHPBD0PADPAVThread@@PAEPAX40HI@Z+0x409 V [jvm.dll+0x8e0255] ?report_and_die@VMError@@SAXPAVThread@@PBDHIW4VMErrorType@@1PAD@Z+0x25 V [jvm.dll+0x3b5db9] ?report_vm_out_of_memory@@YAXPBDHIW4VMErrorType@@0ZZ+0x39 V [jvm.dll+0x1acd82] ??2Chunk@@SAPAXIW4AllocFailEnum@AllocFailStrategy@@I@Z+0x152 V [jvm.dll+0x1ae0c7] ?grow@Arena@@IAEPAXIW4AllocFailEnum@AllocFailStrategy@@@Z+0x27 V [jvm.dll+0x1ad430] ?Amalloc@Arena@@QAEPAXIW4AllocFailEnum@AllocFailStrategy@@@Z+0xf0 V [jvm.dll+0x7ec773] ?allocate_bytes@ResourceArea@@QAEPADIW4AllocFailEnum@AllocFailStrategy@@@Z+0xe3 V [jvm.dll+0x7f6b91] ?resource_allocate_bytes@@YAPADIW4AllocFailEnum@AllocFailStrategy@@@Z+0x61 V [jvm.dll+0x4305d2] ?Dominators@PhaseIdealLoop@@QAEXXZ+0x92 V [jvm.dll+0x68b4de] ?build_and_optimize@PhaseIdealLoop@@AAEX_N0@Z+0x3ee V [jvm.dll+0x36c7e3] ??0PhaseIdealLoop@@QAE@AAVPhaseIterGVN@@_N1@Z+0x53 V [jvm.dll+0x36e3fb] ?Optimize@Compile@@AAEXXZ+0x76b V [jvm.dll+0x36c074] ??0Compile@@QAE@PAVciEnv@@PAVC2Compiler@@PAVciMethod@@H_N33PAVDirectiveSet@@@Z+0xc24 V [jvm.dll+0x2bc5bc] ?compile_method@C2Compiler@@UAEXPAVciEnv@@PAVciMethod@@HPAVDirectiveSet@@@Z+0xec V [jvm.dll+0x37e0a2] ?invoke_compiler_on_method@CompileBroker@@CAXPAVCompileTask@@@Z+0x4d2 V [jvm.dll+0x37d09b] ?compiler_thread_loop@CompileBroker@@SAXXZ+0x29b V [jvm.dll+0x8a51cc] ?thread_main_inner@JavaThread@@QAEXXZ+0xcc V [jvm.dll+0x8a447e] ?run@JavaThread@@UAEXXZ+0x18e V [jvm.dll+0x78386b] ?current_thread_cpu_time_info@os@@SAXPAU_jvmtiTimerInfo@@@Z+0x13b C [msvcr120.dll+0x2c01d] C [msvcr120.dll+0x2c001] C [kernel32.dll+0x1338a] C [ntdll.dll+0x39902] C [ntdll.dll+0x398d5]
19-07-2016
Might need additional ergonomics tunings for 32-bit server JVM's.
18-07-2016
I have win7 64-bit with 16GB and 4 cores. Given it is a 32-bit VM the difference in RAM should be irrelevant. I can't reproduce this. I can only suggest reducing the number of GC and/or Compiler Threads to see if that fixes it. This isn't a regression as the default has changed so you're now running an apple instead of an orange.
12-07-2016
The system is running Window 7 64 bit and has 12GB RAM and an 8 core Xeon CPU (it is a Sun Ultra 27). The "steps to reproduce" are no more complex than I said. Start SwingSet2 and just operate the demo in a simple way (tabbing around, selecting options) and then it dies. It could be the compiler that is the bit that dies. I am attaching the hotspot error log and replay files.
11-07-2016
That said I had no issues with a product build ... or a fastdebug build. Can you be more specific regarding the host environment and the steps to reproduce? Thanks.
11-07-2016
Running server VM with default server ergonomics will completely change memory footprint. Fatal OOM conditions are far more likely now.
11-07-2016