JDK-6898462 : The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,7,8,8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2009-11-05
  • Updated: 2016-05-25
  • Resolved: 2014-12-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 8 JDK 9
8u40Fixed 9 b44Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
See example in attachment. I tested it on my solaris-i586 for JDK7b74.

Here is run string:
/net/vmsqe.russia/export/jdk/re/7/promoted/ea/b74/binaries/solaris-i586/fastdebug/bin/java  -server -Xmixed -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Xmx8M -XX:+DoEscapeAnalysis -cp /export/home/lm153972/NetBeansProjects/Tests/build/classes tests.Main

Here is the result for product:
should not reach here
final
Exception in thread "main" java.lang.NullPointerException
	at tests.Main.eatMemory(Main.java:40)
	at tests.Main.main(Main.java:71)


Here is the result (for fastdebug):
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/vframeArray.cpp:94
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/BUILD_AREA/jdk7/hotspot/src/share/vm/runtime/vframeArray.cpp:94), pid=2482, tid=2
#  Error: assert(!value->obj_is_scalar_replaced(),"object should be reallocated already")
#
# JRE version: 7.0-b74
# Java VM: Java HotSpot(TM) Server VM (17.0-b03-fastdebug mixed mode solaris-x86 )
# An error report file with more information is saved as:
# /export/home/lm153972/NetBeansProjects/testbase/vm/ant-build/hs_err_pid2482.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...
Abort (core dumped)

These tests fails due this issue (they are not excluded from tun):

nsk/monitoring/stress/classload/unload001
nsk/monitoring/stress/classload/unload002
nsk/monitoring/stress/classload/unload003
nsk/monitoring/stress/classload/unload004
nsk/monitoring/stress/classload/unload005
nsk/monitoring/stress/classload/unload006
nsk/monitoring/stress/classload/unload007
nsk/monitoring/stress/classload/unload008
nsk/monitoring/stress/classload/unload009
nsk/monitoring/stress/classload/unload010
nsk/monitoring/stress/classload/unload011
nsk/monitoring/stress/classload/unload012
Also these:-

gc/gctests/LargeObjects/large001/large001
gc/gctests/LargeObjects/large003
gc/gctests/LargeObjects/large004
gc/gctests/LargeObjects/large005
Also fails

gc/gctests/Steal/steal001

Comments
Comment from John (from JDK-8061801): The JVM must not crash. The root cause of this bug is an OOM condition. So throw an OOM, which will not crash the JVM. That will allow the user to observe the problem and try to continue. There is a potential problem in that the OOM may appear to come from a line of code that does not have a visible construct that can throw OOM. But that is a relatively minor problem, since lines of Java code can have implicit conversions (boxing) that might throw OOM.
07-11-2014

RULE gc/lock/jni/jnilock001 Crash Internal Error ...vframeArray.cpp..... RULE gc/lock/jni/jnilock003 Crash Internal Error ...vframeArray.cpp.....
12-04-2013

EVALUATION During deoptimization caused by OutOfMemoryError exception VM can't reallocate a scalar replaced object but it continue the execution with assumtion that the object was reallocated.
07-11-2009