JDK-8134643 : mb/jvm/alloc/PostAllocationStores/testAllocation* fails with out of memory on windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2015-08-28
  • Updated: 2015-10-20
  • Resolved: 2015-10-20
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
9Resolved
Related Reports
Relates :  
JDK-8058952 - G1 sizing policy increases heap according to gc time ratio too aggressively
Description
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 775946240 bytes for Failed to commit area from 0x0000000459800000 to 0x0000000487c00000 of length 775946240.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (C:\jprt\T\P1\185435.rwestrel\s\hotspot\src\os\windows\vm\os_windows.cpp:3328), pid=52168, tid=0x0000000000009de8
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150826185435.rwestrel.8134321-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-20150826185435.rwestrel.8134321-b00, compiled mode, g1 gc, windows-amd64)
# Core dump will be written. Default location: C:\local\aurora\sandbox\results\ResultDir\testAllocationWithNonNullStores\hs_err_pid52168.mdmp
#

V  [jvm.dll+0x4b1f30]  os::platform_print_native_stack+0x100;;  ?platform_print_native_stack@os@@SA_NPEAVoutputStream@@PEAXPEADH@Z+0x100
V  [jvm.dll+0x38e22c]  VMError::report+0xb3c;;  ?report@VMError@@AEAAXPEAVoutputStream@@@Z+0xb3c
V  [jvm.dll+0x38ee63]  VMError::report_and_die+0x413;;  ?report_and_die@VMError@@QEAAXXZ+0x413
V  [jvm.dll+0x37fbf6]  report_vm_out_of_memory+0x76;;  ?report_vm_out_of_memory@@YAXPEBDH_KW4VMErrorType@@0@Z+0x76
V  [jvm.dll+0x3dd267]  os::pd_commit_memory_or_exit+0x97;;  ?pd_commit_memory_or_exit@os@@CAXPEAD_K_NPEBD@Z+0x97
V  [jvm.dll+0x3020fb]  os::commit_memory_or_exit+0x2b;;  ?commit_memory_or_exit@os@@SAXPEAD_K1_NPEBD@Z+0x2b
V  [jvm.dll+0x5aede5]  G1PageBasedVirtualSpace::commit_preferred_pages+0xf5;;  ?commit_preferred_pages@G1PageBasedVirtualSpace@@AEAAX_K0@Z+0xf5
V  [jvm.dll+0x5aecb3]  G1PageBasedVirtualSpace::commit_internal+0x133;;  ?commit_internal@G1PageBasedVirtualSpace@@AEAAX_K0@Z+0x133
V  [jvm.dll+0x5aeb3d]  G1PageBasedVirtualSpace::commit+0x9d;;  ?commit@G1PageBasedVirtualSpace@@QEAA_N_K0@Z+0x9d
V  [jvm.dll+0x5b0ca6]  G1RegionsLargerThanCommitSizeMapper::commit_regions+0x46;;  ?commit_regions@G1RegionsLargerThanCommitSizeMapper@@UEAAXI_K@Z+0x46
V  [jvm.dll+0x5bc574]  HeapRegionManager::commit_regions+0x94;;  ?commit_regions@HeapRegionManager@@AEAAXI_K@Z+0x94
V  [jvm.dll+0x5bd230]  HeapRegionManager::make_regions_available+0x80;;  ?make_regions_available@HeapRegionManager@@AEAAXII@Z+0x80
V  [jvm.dll+0x5bc660]  HeapRegionManager::expand_at+0x90;;  ?expand_at@HeapRegionManager@@QEAAIII@Z+0x90
V  [jvm.dll+0x5777ec]  G1CollectedHeap::expand+0x17c;;  ?expand@G1CollectedHeap@@QEAA_N_K@Z+0x17c
V  [jvm.dll+0x57557c]  G1CollectedHeap::do_collection_pause_at_safepoint+0xaac;;  ?do_collection_pause_at_safepoint@G1CollectedHeap@@IEAA_NN@Z+0xaac
V  [jvm.dll+0x5c7e96]  VM_G1IncCollectionPause::doit+0x136;;  ?doit@VM_G1IncCollectionPause@@UEAAXXZ+0x136
V  [jvm.dll+0x349a14]  VM_Operation::evaluate+0x104;;  ?evaluate@VM_Operation@@QEAAXXZ+0x104
V  [jvm.dll+0x346fb8]  VMThread::evaluate_operation+0x158;;  ?evaluate_operation@VMThread@@AEAAXPEAVVM_Operation@@@Z+0x158
V  [jvm.dll+0x347995]  VMThread::loop+0x465;;  ?loop@VMThread@@QEAAXXZ+0x465
V  [jvm.dll+0x348118]  VMThread::run+0xd8;;  ?run@VMThread@@UEAAXXZ+0xd8
V  [jvm.dll+0x3dba0e]  java_start+0xde;;  ?java_start@@YAIPEAVThread@@@Z+0xde
Comments
Failure related to external (not JVM) processes occupied swap space needed.
20-10-2015
Finally i would agree with Thomas comment. That machine has 192G. MaxRAMFraction is 8, so at most it should set -Xmx to ~24G. Log files shows that heap size at the moment of failure was ~12G. Swap space went down to 718M. At this moment request for expansion of heap for 740M failed because of lack of swap space. Failure definitely related to something outside of control by JVM (heap was under Xmx) - other processes took away swap. Looks like no bug here.
13-10-2015
Hi Roland, It looks like this failure occurred on your private build. I am looking what turned on grows of heap. Could you describe what were your changes (if any) in this build? Alex
08-09-2015
That machine has 192G. MaxRAMFraction is 8, so at most it should set -Xmx to ~24G. Is it possible that the machine is just too loaded (all memory committed)? Or can that be reproduced on any machine with the given settings?
08-09-2015
Problem is that memory was wasted on GCTimeRatio driven heap expansion. Expansion doubled heap at the beginning, expanded by available amount when doubling became impossible and crash (on Windows) after all. Only first of those expansions may (or may not) was necessary. It was possible to reproduce crash with flags : -Xmx32g -XX:GCTimeRatio=999999 -XX:G1MaxNewSizePercent=1 -XX:G1NewSizePercent=1 Basically we got duplicate of JDK-8058952 - G1 sizing policy increases heap according to gc time ratio too aggressively
04-09-2015