JDK-8153540 : C2 intrinsic for Unsafe.allocateInstance doesn't properly filter out array classes
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u66,10,11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-04-05
  • Updated: 2020-08-07
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.
Other
tbdUnresolved
Related Reports
Duplicate :  
Relates :  
Description
While testing Graal we tripped across an assertion failure with C2.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/slave/buildlog/binary-jdk9-fastdebug-OJNGraalJDK9_ssw_amd64_linux/build/hotspot/src/share/vm/oops/klass.hpp:316), pid=30394, tid=30395
#  assert(lh > (jint)_lh_neutral_value) failed: must be instance
#
# JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-03-25-125435..build)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-2016-03-25-125435..build, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /slave/buildlog/CI-graal-core_gate_amd64_linux_postgate_jdk9-SNAPSHOT-fastdebug_jdk8_jdk7/build/graal-core/core.30394)
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -Djvmci.Compiler=graal -Xbootclasspath/p:/slave/buildlog/CI-graal-core_gate_amd64_linux_postgate_jdk9-SNAPSHOT-fastdebug_jdk8_jdk7/build/truffle/mxbuild/dists/truffle-api.jar:/slave/buildlog/CI-graal-core_gate_amd64_linux_postgate_jdk9-SNAPSHOT-fastdebug_jdk8_jdk7/build/graal-core/mxbuild/dists/graal.jar -esa -ea -Djava.awt.headless=true com.oracle.mxtool.junit.MxJUnitWrapper -JUnitVerbose -JUnitFailFast -JUnitEnableTiming -JUnitEagerStackTrace @/tmp/mxtoolc1shvd.testclasses

Host: ce9e05124607, Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 8 cores, 15G, Ubuntu 14.04.3 LTS
Time: Fri Apr  1 11:14:47 2016 UTC elapsed time: 33 seconds (0d 0h 0m 33s)

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

Current thread (0x00007fc15801b800):  JavaThread "main" [_thread_in_vm, id=30395, stack(0x00007fc1619c2000,0x00007fc161ac3000)]

Stack: [0x00007fc1619c2000,0x00007fc161ac3000],  sp=0x00007fc161abf2d0,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x119f775]  VMError::report(outputStream*, bool)+0xfb3
V  [libjvm.so+0x11a1522]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x498
V  [libjvm.so+0x11a0fda]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x7e
V  [libjvm.so+0x917b49]  report_vm_error(char const*, int, char const*, char const*, ...)+0x105
V  [libjvm.so+0x5a9b4b]  Klass::layout_helper_needs_slow_path(int)+0x45
V  [libjvm.so+0x1038446]  OptoRuntime::new_instance_C(Klass*, JavaThread*)+0x18e
v  ~RuntimeStub::_new_instance_Java
J 3490 C2 sun.misc.Unsafe.allocateInstance(Ljava/lang/Class;)Ljava/lang/Object; (8 bytes) @ 0x00007fc14cd1a9d8 [0x00007fc14cd1a900+0x00000000000000d8]
j  com.oracle.graal.jtt.jdk.UnsafeAllocateInstance01.testClassForException(Ljava/lang/Class;)V+4
v  ~StubRoutines::call_stub
Comments
Isn't this a bug in the caller? The comment from sun.misc.Unsafe says: * <em>Note:</em> It is the resposibility of the caller to make sure * arguments are checked before methods of this class are * called. While some rudimentary checks are performed on the input, * the checks are best effort and when performance is an overriding * priority, as when methods of this class are optimized by the * runtime compiler, some or all checks (if any) may be elided. Hence, * the caller must not rely on the checks and corresponding * exceptions!
06-04-2018

ILW = assert; Unsafe with Graal only; none = MLH = P4
09-06-2016

The problem seems to be that Unsafe.allocateInstance doesn't check for array classes. If you allocate enough then it has to slow path into new_instance_C and discovers the problem there. Running the attached test case illustrates the problem. $ ../build/macosx-x86_64-normal-server-fastdebug/jdk/bin/java -server AllocateInstance # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/klass.hpp:316 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/tkrodrig/ws/hs-comp/hotspot/src/share/vm/oops/klass.hpp:316), pid=45447, tid=6147 # assert(lh > (jint)_lh_neutral_value) failed: must be instance # # JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-03-16-092550.tkrodrig.hs-comp) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-03-16-092550.tkrodrig.hs-comp, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/tkrodrig/ws/hs-comp/hotspot/hs_err_pid45447.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 6147 It also fails in 8u66 which was the earliest release I tested.
05-04-2016