JDK-8016057 : OOME crash in tests
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2013-06-06
  • Updated: 2013-10-02
  • Resolved: 2013-10-02
Related Reports
Relates :  
JDK-8023056 - use C++ exceptions for out of memory situations in the compilers
Description
during  promotion testing for JDK8 b92  vm/mlvm/meth/stress/jdi/breakpointInCompiledCode has crashed due to OOME in compiler thread

;; Using jvm: "/bpool/local/aurora/sandbox/java/re/jdk/8/promoted/all/b92/binaries/solaris-amd64/jre/lib/amd64/server/libjvm.so"
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 2097168 bytes for Chunk::new
# 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 (allocation.cpp:388), pid=15723, tid=33
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b34 mixed mode solaris-amd64 compressed oops)
# Core dump written. Default location: /bpool/local/aurora/sandbox/results/ResultDir/breakpointInCompiledCode_copy_1/core or core.15723
#

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

Current thread (0x0000000000658800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=33, stack(0xfffffd7fed8d9000,0xfffffd7fed9d9000)]

Stack: [0xfffffd7fed8d9000,0xfffffd7fed9d9000],  sp=0xfffffd7fed9ce7b0,  free space=981k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12550e6]  void VMError::report(outputStream*)+0x91e;;  __1cHVMErrorGreport6MpnMoutputStream__v_+0x91e
V  [libjvm.so+0x12565d6]  void VMError::report_and_die()+0x636;;  __1cHVMErrorOreport_and_die6M_v_+0x636
V  [libjvm.so+0x8d6615]  void report_vm_out_of_memory(const char*,int,unsigned long,VMErrorType,const char*)+0x89;;  __1cXreport_vm_out_of_memory6FpkciLnLVMErrorType_1_v_+0x89
V  [libjvm.so+0x560e8e]  void*Arena::grow(unsigned long,AllocFailStrategy::AllocFailEnum)+0x2f2;;  __1cFArenaEgrow6MLnRAllocFailStrategyNAllocFailEnum__pv_+0x2f2
V  [libjvm.so+0x56107a]  void*Arena::Arealloc(void*,unsigned long,unsigned long,AllocFailStrategy::AllocFailEnum)+0x112;;  __1cFArenaIArealloc6MpvLLnRAllocFailStrategyNAllocFailEnum__1_+0x112
V  [libjvm.so+0xf4b4e6]  void Node_Array::grow(unsigned)+0x9a;;  __1cKNode_ArrayEgrow6MI_v_+0x9a
V  [libjvm.so+0x84c3eb]  void Compile::identify_useful_nodes(Unique_Node_List&)+0x2f;;  __1cHCompileVidentify_useful_nodes6MrnQUnique_Node_List__v_+0x2f
V  [libjvm.so+0x1005374]  PhaseRemoveUseless::PhaseRemoveUseless #Nvariant 1(PhaseGVN*,Unique_Node_List*)+0x108;;  __1cSPhaseRemoveUseless2t6MpnIPhaseGVN_pnQUnique_Node_List__v_+0x108
V  [libjvm.so+0x852edf]  void Compile::inline_incrementally(PhaseIterGVN&)+0x48b;;  __1cHCompileUinline_incrementally6MrnMPhaseIterGVN__v_+0x48b
V  [libjvm.so+0x853576]  void Compile::Optimize()+0x1e6;;  __1cHCompileIOptimize6M_v_+0x1e6
V  [libjvm.so+0x84e33b]  Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool)+0xfdf;;  __1cHCompile2t6MpnFciEnv_pnKC2Compiler_pnIciMethod_ibbb_v_+0xfdf
V  [libjvm.so+0x76ac33]  void C2Compiler::compile_method(ciEnv*,ciMethod*,int)+0xb3;;  __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb3
V  [libjvm.so+0x86658a]  void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa82;;  __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0xa82
V  [libjvm.so+0x865187]  void CompileBroker::compiler_thread_loop()+0xa47;;  __1cNCompileBrokerUcompiler_thread_loop6F_v_+0xa47
V  [libjvm.so+0x119876f]  void JavaThread::run()+0x4f3;;  __1cKJavaThreadDrun6M_v_+0x4f3
V  [libjvm.so+0xf9383e]  java_start+0x9d2;;  java_start+0x9d2
C  [libc.so.1+0x12257d]  _thrp_setup+0xa5;;  _thrp_setup+0xa5
C  [libc.so.1+0x122820]  _lwp_start+0x0;;  _lwp_start+0x0


Current CompileTask:
C2:   5840  749             java.lang.invoke.LambdaForm$MH/1825027294::collect (101 bytes)
 

A new failure, same thing, OOME:
java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
Comments
Similar OOME as other Solaris X86 bugs
02-10-2013
JDK-8021881 might be a duplicate of this one. I'm linking them for now.
19-08-2013
-XX:HeapBaseMinAddress=2g is another workaround
15-08-2013
Try using libumem as an alternative malloc to see if this issue is Solaris malloc related. How to use libumem: LD_PRELOAD=libumem.so $JAVA_HOME/bin/java ... The other option is to set HeapBaseMinAddress to 2gb for the tests.
15-08-2013
Bumped to P1 as it breaks Nashorn performance measurement on Solaris.
14-08-2013
Octane benchmarks stress Nashorn, which put a significant pressure on JSR292 and inliner.
07-08-2013
Looks like the same issue caused microbenchmarks performance tests to cause JVM Crashes on Solaris 11 amd64 against JDK 8. To reproduce download attached microbench_crash.zip, there you can find hs_err files and microbenchmarks.jar file. Type in terminal: ${JDK8}/bin/java -XX:+TieredCompilation -XX:+UseParallelGC -Xms2g -Xmx2g -Dengine=nashorn -jar microbenchmarks.jar .*octane.* -wi 1 -i 1 -f 1 to reproduce crash.
07-08-2013
Some runs also fail with: Internal Error (/tmp/workspace/2-build-solaris-amd64/jdk8/4590/hotspot/src/share/vm/opto/node.cpp:71), pid=4749, tid=34 assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit
13-06-2013