JDK-8008308 : gc/gctests/ManyObjects VM crashes with growableArray.cpp. Out of swap space?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86
  • Submitted: 2013-02-15
  • Updated: 2013-09-12
  • Resolved: 2013-02-26
Related Reports
Relates :  
Description
Test: gc/gctests/ManyObjects	execute_positive
vm option: -server -Xcomp -XX:+UseG1GC
vm platform: win-x86-32

;; Using jvm: "C:/local/aurora/sandbox/jdk/baseline/windows-i586/jre/bin/server/jvm.dll"
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 41943040 bytes for AllocateHeap
# 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 (memory/allocation.inline.hpp:60), pid=30420, tid=137280
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b76) (build 1.8.0-ea-b76)
# Java VM: Java HotSpot(TM) Server VM (25.0-b17 compiled mode windows-x86 )
# Core dump written. Default location: C:\local\aurora\sandbox\results\ResultDir\ManyObjects\hs_err_pid30420.mdmp
#

---------------  T H R E A D  ---------------

Current thread (0x004cb800):  GCTaskThread [stack: 0x08fe0000,0x09030000] [id=137280]

Stack: [0x08fe0000,0x09030000],  sp=0x0902eb8c,  free space=314k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x194a91]  VMError::report_and_die+0x561;;  ?report_and_die@VMError@@QAEXXZ+0x561
V  [jvm.dll+0x18e8c5]  report_vm_out_of_memory+0x45;;  ?report_vm_out_of_memory@@YAXPBDHI0@Z+0x45
V  [jvm.dll+0x18fa06]  GenericGrowableArray::raw_allocate+0x66;;  ?raw_allocate@GenericGrowableArray@@IAEPAXH@Z+0x66
V  [jvm.dll+0x2dfb04]  GrowableArray<PhiNode *>::grow+0x34;;  ?grow@?$GrowableArray@VinstanceHandle@@@@AAEXH@Z+0x34
V  [jvm.dll+0x2638df]  G1CollectedHeap::preserve_mark_if_necessary+0x13f;;  ?preserve_mark_if_necessary@G1CollectedHeap@@IAEXPAVoopDesc@@PAVmarkOopDesc@@@Z+0x13f
V  [jvm.dll+0x263d6c]  G1CollectedHeap::handle_evacuation_failure_common+0x1c;;  ?handle_evacuation_failure_common@G1CollectedHeap@@IAEXPAVoopDesc@@PAVmarkOopDesc@@@Z+0x1c
V  [jvm.dll+0x26478d]  G1CollectedHeap::handle_evacuation_failure_par+0x4d;;  ?handle_evacuation_failure_par@G1CollectedHeap@@IAEPAVoopDesc@@PAVOopsInHeapRegionClosure@@PAV2@@Z+0x4d
V  [jvm.dll+0x2648eb]  G1ParCopyClosure<0,2,0>::copy_to_survivor_space+0x10b;;  ?copy_to_survivor_space@?$G1ParCopyClosure@$0A@$0A@$0A@@@IAEPAVoopDesc@@PAV2@@Z+0x10b
V  [jvm.dll+0x264abd]  G1ParCopyClosure<0,2,0>::do_oop_work<oopDesc *>+0x6d;;  ??$do_oop_work@PAVoopDesc@@@?$G1ParCopyClosure@$0A@$01$0A@@@AAEXPAPAVoopDesc@@@Z+0x6d
V  [jvm.dll+0x265286]  G1ParScanThreadState::deal_with_reference+0x96;;  ?deal_with_reference@G1ParScanThreadState@@QAEXVStarTask@@@Z+0x96
V  [jvm.dll+0x26533c]  G1ParScanThreadState::trim_queue+0xac;;  ?trim_queue@G1ParScanThreadState@@QAEXXZ+0xac
V  [jvm.dll+0x26546d]  G1ParEvacuateFollowersClosure::do_void+0x1d;;  ?do_void@G1ParEvacuateFollowersClosure@@UAEXXZ+0x1d
V  [jvm.dll+0x2659f3]  G1ParTask::work+0x393;;  ?work@G1ParTask@@UAEXI@Z+0x393
V  [jvm.dll+0x195462]  GangWorker::loop+0x92;;  ?loop@GangWorker@@MAEXXZ+0x92
V  [jvm.dll+0x1a4496]  java_start+0x86;;  ?java_start@@YGIPAVThread@@@Z+0x86
C  [msvcr100.dll+0x10fac]
C  [msvcr100.dll+0x110b1]
C  [kernel32.dll+0x8f299]
C  [ntdll.dll+0x7d819]
C  [ntdll.dll+0x7da2b]

Comments
The change that Bengt made (using two instances of Stack<> instead of two growable arrays) was pushed on the following dates: hs24: 2013-02-11 16:44:20 +0000 hotspot-gc: 2013-02-10 23:37:06 +0000 hs25: 2013-02-15 23:33:19 +0000 It was included in b19 of hs25 and was backported to 8 on 2013-02-20 01:58:09 +0000. It was included in b78 of jdk8. So this should no longer be an issue.
26-02-2013