JDK-8231515 : [Graal] Crash during exception throwing in InterpreterRuntime::resolve_invoke
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-09-26
  • Updated: 2020-06-04
  • Resolved: 2020-01-23
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 11 JDK 14 JDK 15
11.0.8-oracleFixed 14 b34Fixed 15Fixed
Related Reports
Duplicate :  
JDK-8233576 - [Graal] guarantee(oopDesc::is_oop_or_null(obj)) failed: invalid oop
Relates :  
JDK-8229201 - Update Graal
Description
Stress test start failing in jdk-14+16-664. Failures reproduced with 
applications/kitchensink/Kitchensink24HStress.java with JVMCI enabled.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/runtime/handles.cpp:36), pid=21561, tid=21589
#  assert(oopDesc::is_oop(obj)) failed: not an oop: 0x00007f5999cfb678
#
# JRE version: Java(TM) SE Runtime Environment (14.0+16) (fastdebug build 14-ea+16-664)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+16-664, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd305a8]  HandleArea::allocate_handle(oop)+0x158
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/fcf4c0c4-d73e-4321-860c-6613427db92b-S798/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/91c7be30-755e-4ba7-bff9-3a2347ef69b5/runs/b4997c3f-c44a-4f80-9eed-eb3441a528f9/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/core.21561)
#
# 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: -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=6 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -ea -esa -XX:MaxRAMPercentage=50 -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/fcf4c0c4-d73e-4321-860c-6613427db92b-S798/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/91c7be30-755e-4ba7-bff9-3a2347ef69b5/runs/b4997c3f-c44a-4f80-9eed-eb3441a528f9/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/java.io.tmpdir -Duser.home=/opt/mach5/mesos/work_dir/slaves/fcf4c0c4-d73e-4321-860c-6613427db92b-S798/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/91c7be30-755e-4ba7-bff9-3a2347ef69b5/runs/b4997c3f-c44a-4f80-9eed-eb3441a528f9/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/user.home -agentpath:/opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.test/hotspot/jtreg/native/libJvmtiStressModule.so -XX:NativeMemoryTracking=detail applications.kitchensink.process.stress.Main /opt/mach5/mesos/work_dir/slaves/fcf4c0c4-d73e-4321-860c-6613427db92b-S798/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/91c7be30-755e-4ba7-bff9-3a2347ef69b5/runs/b4997c3f-c44a-4f80-9eed-eb3441a528f9/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/kitchensink.final.properties

Host:  Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 8 cores, 58G, Oracle Linux Server release 7.6
Time: Thu Sep 26 04:23:04 2019 UTC elapsed time: 8490 seconds (0d 2h 21m 30s)

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

Current thread (0x00007f5a0c7f0800):  JavaThread "ExceptionStressModule" [_thread_in_vm, id=21589, stack(0x00007f5999bfc000,0x00007f5999cfd000)]

Stack: [0x00007f5999bfc000,0x00007f5999cfd000],  sp=0x00007f5999cfb400,  free space=1021k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd305a8]  HandleArea::allocate_handle(oop)+0x158
V  [libjvm.so+0x80778f]  Handle::Handle(Thread*, oop)+0x9f
V  [libjvm.so+0xdf3b48]  InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x318
V  [libjvm.so+0xdf6863]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x133
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.runToString(Ljava/lang/Object;)V+1
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.testCallNullPointer()V+4
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.runOneIteration()V+49
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.execute()V+20
j  applications.kitchensink.process.stress.modules.StressModule.run()V+109
v  ~StubRoutines::call_stub
V  [libjvm.so+0xe047dc]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6ac
V  [libjvm.so+0xe0187f]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x33f
V  [libjvm.so+0xe01a9a]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xca
V  [libjvm.so+0xf4d8b7]  thread_entry(JavaThread*, Thread*)+0x127
V  [libjvm.so+0x16eb3b2]  JavaThread::thread_main_inner()+0x312
V  [libjvm.so+0x16f3581]  JavaThread::run()+0x2b1
V  [libjvm.so+0x16f0506]  Thread::call_run()+0xf6
V  [libjvm.so+0x141273e]  thread_native_entry(Thread*)+0x10e

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.runToString(Ljava/lang/Object;)V+1
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.testCallNullPointer()V+4
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.runOneIteration()V+49
j  applications.kitchensink.process.stress.modules.ExceptionStressModule.execute()V+20
j  applications.kitchensink.process.stress.modules.StressModule.run()V+109
v  ~StubRoutines::call_stub
Register to memory mapping:

RAX=0x00007f5a149bf000 points into unknown readable memory: 58 00 00 00 00 00 00 00
RBX=0x00007f5a0c7f18e0 points into unknown readable memory: 28 6f c8 13 5a 7f 00 00
RCX=0x00007f5a138ed42d: <offset 0x0000000001a2f42d> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
RDX=0x00007f5a1376fcc0: <offset 0x00000000018b1cc0> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
RSP=0x00007f5999cfb400 is pointing into the stack for thread: 0x00007f5a0c7f0800
RBP=0x00007f5999cfb450 is pointing into the stack for thread: 0x00007f5a0c7f0800
RSI=0x0000000000000024 is an unknown value
RDI=0x00007f5a137ecef0: <offset 0x000000000192eef0> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
R8 =0x00007f5999cfb678 is pointing into the stack for thread: 0x00007f5a0c7f0800
R9 =0x0000000000000100 is an unknown value
R10=0x00007f5a13d879a0: <offset 0x0000000001ec99a0> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
R11=0x0 is NULL
R12=0x00007f5a13d3e88a: <offset 0x0000000001e8088a> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
R13=0x00007f5999cfb468 is pointing into the stack for thread: 0x00007f5a0c7f0800
R14=0x00007f5999cfb418 is pointing into the stack for thread: 0x00007f5a0c7f0800
R15=0x0 is NULL


Registers:
RAX=0x00007f5a149bf000, RBX=0x00007f5a0c7f18e0, RCX=0x00007f5a138ed42d, RDX=0x00007f5a1376fcc0
RSP=0x00007f5999cfb400, RBP=0x00007f5999cfb450, RSI=0x0000000000000024, RDI=0x00007f5a137ecef0
R8 =0x00007f5999cfb678, R9 =0x0000000000000100, R10=0x00007f5a13d879a0, R11=0x0000000000000000
R12=0x00007f5a13d3e88a, R13=0x00007f5999cfb468, R14=0x00007f5999cfb418, R15=0x0000000000000000
RIP=0x00007f5a12bee5a8, EFLAGS=0x0000000000010246, CSGSFS=0x002b000000000033, ERR=0x0000000000000006
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f5999cfb400)
0x00007f5999cfb400:   00007f59a92c5fa8 00007f5a13c8bd68
0x00007f5999cfb410:   00007f5999cfb450 00007f5999cfb678
0x00007f5999cfb420:   00007f5a0c7f0800 00007f5a13d3e88a
0x00007f5999cfb430:   00007f5999cfb468 00007f5a0c7f18e0 

Instructions: (pc=0x00007f5a12bee5a8)
0x00007f5a12bee4a8:   00 41 89 c7 0f 85 0e 01 00 00 45 84 ff 0f 84 c5
0x00007f5a12bee4b8:   00 00 00 49 8b 45 00 41 80 3c 24 00 48 89 45 c8
0x00007f5a12bee4c8:   0f 85 a2 00 00 00 48 8d 05 dc 04 15 01 80 38 00
0x00007f5a12bee4d8:   74 2e be 08 00 00 00 48 89 df e8 39 39 8c ff 48
0x00007f5a12bee4e8:   8b 55 c8 48 89 10 41 80 3c 24 00 75 55 48 83 c4
0x00007f5a12bee4f8:   28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 40 00
0x00007f5a12bee508:   48 8b 43 20 48 83 f8 f7 76 18 48 8d 15 10 75 cf
0x00007f5a12bee518:   00 be 08 00 00 00 48 89 df e8 8a 31 8c ff 48 8b
0x00007f5a12bee528:   43 20 48 8d 50 08 48 3b 53 28 0f 87 28 01 00 00
0x00007f5a12bee538:   48 89 53 20 48 8b 55 c8 48 89 10 41 80 3c 24 00
0x00007f5a12bee548:   74 ab 4c 89 f7 48 89 45 b8 e8 1a d4 6c 00 48 8b
0x00007f5a12bee558:   45 b8 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d
0x00007f5a12bee568:   c3 0f 1f 80 00 00 00 00 4c 89 f7 e8 e8 d2 6c 00
0x00007f5a12bee578:   e9 51 ff ff ff 0f 1f 00 48 8d 05 79 2e 0a 01 4d
0x00007f5a12bee588:   8b 45 00 48 8d 0d 9b ee cf 00 48 8d 15 27 17 b8
0x00007f5a12bee598:   00 be 24 00 00 00 48 8d 3d 4b e9 bf 00 48 8b 00
0x00007f5a12bee5a8:   c6 00 58 31 c0 e8 9e 23 d6 ff e8 c9 9b 6d 00 e9
0x00007f5a12bee5b8:   ff fe ff ff 0f 1f 40 00 4c 89 f7 e8 a8 d3 6c 00
0x00007f5a12bee5c8:   e9 e5 fe ff ff 0f 1f 00 4c 89 f7 e8 88 d2 6c 00
0x00007f5a12bee5d8:   e9 bd fe ff ff 0f 1f 00 48 8d 05 19 2e 0a 01 48
0x00007f5a12bee5e8:   8d 0d 32 e9 bf 00 48 8d 15 53 e9 bf 00 be 23 00
0x00007f5a12bee5f8:   00 00 48 8d 3d ef e8 bf 00 48 8b 00 c6 00 58 31
0x00007f5a12bee608:   c0 e8 42 23 d6 ff e8 6d 9b 6d 00 e9 64 fe ff ff
0x00007f5a12bee618:   0f 1f 84 00 00 00 00 00 48 8d 05 d9 2d 0a 01 48
0x00007f5a12bee628:   8d 0d 62 e8 bf 00 48 8d 15 93 e8 bf 00 be 22 00
0x00007f5a12bee638:   00 00 48 8d 3d af e8 bf 00 48 8b 00 c6 00 58 31
0x00007f5a12bee648:   c0 e8 02 23 d6 ff e8 2d 9b 6d 00 e9 19 fe ff ff
0x00007f5a12bee658:   0f 1f 84 00 00 00 00 00 31 d2 be 08 00 00 00 48
0x00007f5a12bee668:   89 df e8 71 30 8c ff e9 73 fe ff ff 66 90 66 2e
0x00007f5a12bee678:   0f 1f 84 00 00 00 00 00 48 8d 05 29 5f fb 00 48
0x00007f5a12bee688:   89 07 48 8b 47 08 48 85 c0 0f 84 29 01 00 00 55
0x00007f5a12bee698:   48 89 e5 41 56 41 55 49 89 fd 41 54 53 48 8b 57 


Stack slot to memory mapping:
stack at sp + 0 slots: {method} {0x00007f59a92c5fa8} 'runToString' '(Ljava/lang/Object;)V' in 'applications/kitchensink/process/stress/modules/ExceptionStressModule'
stack at sp + 1 slots: 0x00007f5a13c8bd68: <offset 0x0000000001dcdd68> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
stack at sp + 2 slots: 0x00007f5999cfb450 is pointing into the stack for thread: 0x00007f5a0c7f0800
stack at sp + 3 slots: 0x00007f5999cfb678 is pointing into the stack for thread: 0x00007f5a0c7f0800
stack at sp + 4 slots: 0x00007f5a0c7f0800 is a thread
stack at sp + 5 slots: 0x00007f5a13d3e88a: <offset 0x0000000001e8088a> in /opt/mach5/mesos/work_dir/jib-master/install/jdk-14+16-664/linux-x64-debug.jdk/jdk-14/fastdebug/lib/server/libjvm.so at 0x00007f5a11ebe000
stack at sp + 6 slots: 0x00007f5999cfb468 is pointing into the stack for thread: 0x00007f5a0c7f0800
stack at sp + 7 slots: 0x00007f5a0c7f18e0 points into unknown readable memory: 28 6f c8 13 5a 7f 00 00
Comments
Okay.
31-03-2020
The JVMCI parts are certainly needed. I think the version of Graal in 11 isn't exposed to this problem though because it's not inserting the a deopt in the exception path, so I don't think you need to backport the Graal changes. I think they won't apply there anyway unless you do a full sync with Graal which I don't think we want.
31-03-2020
[~dnsimon][~never] Do you need this fix backported to 11u?
31-03-2020
Changeset: 2f2594d5 Author: Tom Rodriguez <never@openjdk.org> Date: 2020-01-23 08:43:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f2594d5
07-02-2020
Checked that applications/kitchensink/Kitchensink24HStress.java passed in latest CI
31-01-2020
URL: https://hg.openjdk.java.net/jdk/jdk14/rev/db2cc624c238 User: never Date: 2020-01-23 17:02:01 +0000
23-01-2020
Fix Request This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. The second issue is related but more rare where our support for explicit exception throwing uses a stub that has a FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less likely. New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. Minor changes to JVMCI were made to expose information to Graal but there are no change that would affect anything besides Graal. New unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates that there were no more crashes with Graal. preliminary mach5 testing against 15 was clean but a webrev and mach5 testing against jdk 14 have been prepared. [~dlong] reviewed the changes in the Graal PR and I'm sending out the RFR now. webrev for jdk14 at http://cr.openjdk.java.net/~never/8231515/webrev
17-01-2020
Fix request approved.
17-01-2020
Yes, this seems to be caused by https://github.com/oracle/graal/commit/034380de4c518abb63f1453ac7364a1a63c66a27 When graal emits explicit exception throws during parsing like for an NPE we emit the _should_post_on_exceptions_flag check with a deopt at the end but we aren't being careful about the FrameState assigned to that deopt, so we end up with the FrameState that would be used for creating the exception but this FrameState doesn't have the rethrowException flag set so we just end up reexecuting at the bci but without the right number of arguments on the stack.
31-10-2019
JVMCI has a notion of rethrow_exception where an exception to be rethrown is on the top of stack and the VerifyStack logic doesn't have a special case for this which is why it's complaining. Fixing the assert silences the message but I suspect that we should be dropping that value from the interpreter frames when we rematerialize them. Otherwise there's an extra value on the interpreter stack. It's likely that this problem is becoming visible because of our changes to support JavaThread::_should_post_on_exceptions_flag as we now deopt in the exception path using this FrameState.
30-10-2019
Looking more closely at the HotSpotJITClassInitializationPlugin it should be a no-op in jdk-14 because JavaThread::_init_thread isn't visible through JVMCI. That plugin is only installed if it's visible. https://github.com/oracle/graal/commit/79d02821435b21ae54458501e0d35c005b543460#diff-05f52b975038f286ba24b315833bbb8dR157 In that case the whole change should be a nop. You can see when you run the unit test for this against on 14 it's skipped for this reason. org.graalvm.compiler.hotspot.test.HotSpotClassInitializationTest started (1 of 1) testInvokeStatic: (init_thread field must be visible) Passed 4.3 ms testNewInstance: (init_thread field must be visible) Passed 0.9 ms testGetStatic: (init_thread field must be visible) Passed 0.4 ms org.graalvm.compiler.hotspot.test.HotSpotClassInitializationTest finished 7.8 ms Anyway, I'm able to run kitchensink now so I'll try to track it down.
29-10-2019
I think Doug is right and it's related to the HotSpotJITClassInitializationPlugin change. I disabled the plugin and haven't been able to reproduce the problem again. [~never] Tom, I've reassigned it to you.
02-10-2019
Reproduced with -XX:+VerifyStack -XX:+DeoptimizeALot in 22 minutes. Wrong number of expression stack elements during deoptimization Error occurred while verifying frame 0 (0..1, 0 is topmost) Fabricated interpreter frame had 1 expression stack elements Interpreter oop map had 0 expression stack elements try_next_mask = 0 next_mask_expression_stack_size = -1 callee_size_of_parameters = 0 callee_max_locals = 0 top_frame_expression_stack_adjustment = 0 exec_mode = 1 cur_invoke_parameter_size = 6 Thread = 0x00007fb5c46cc000, thread ID = 2935 Interpreted frames: com.sun.crypto.provider.CipherCore.finalNoPadding([BI[BII)I (bci 166) com.sun.crypto.provider.CipherCore.fillOutputBuffer([BI[BII[B)I (bci 8) - sp: 0x00007fb58d3e3940 - thread: "MainThread" #13 prio=5 os_prio=0 cpu=1282811.22ms elapsed=1329.85s tid=0x00007fb5c46cc000 nid=0xb77 runnable [0x00007fb58d3e2000] java.lang.Thread.State: RUNNABLE Thread: 0x00007fb5c46cc000 [0xb77] State: _running _at_poll_safepoint 0 JavaThread state: _thread_in_Java - frame size: 8 - interpreter_frame -> sp: 0x00007fb58d3e3878 - interpreter_frame -> sp: 0x00007fb58d3e38d8
02-10-2019
Event: 8490.174 Thread 0x00007f5a0c7f0800 Uncommon trap: trap_request=0xffffff2f fr.pc=0x00007f59fc4d2faf relative=0x000000000000008f Event: 8490.174 Thread 0x00007f5a0c7f0800 Uncommon trap: reason=transfer_to_interpreter action=none pc=0x00007f59fc4d2faf method=applications.kitchensink.process.stress.modules.ExceptionStressModule.testSuperNullPointer()V @ 0 jvmci Event: 8490.174 Thread 0x00007f5a0c7f0800 DEOPT PACKING pc=0x00007f59fc4d2faf sp=0x00007f5999cfb730 Event: 8490.174 Thread 0x00007f5a0c7f0800 DEOPT UNPACKING pc=0x00007f59efb156d3 sp=0x00007f5999cfabd0 mode 3 Event: 8490.174 Thread 0x00007f5a0c7f0800 Uncommon trap: trap_request=0xffffff2f fr.pc=0x00007f59fc4d44af relative=0x000000000000008f Event: 8490.174 Thread 0x00007f5a0c7f0800 Uncommon trap: reason=transfer_to_interpreter action=none pc=0x00007f59fc4d44af method=applications.kitchensink.process.stress.modules.ExceptionStressModule.testCallNullPointer()V @ 0 jvmci Event: 8490.174 Thread 0x00007f5a0c7f0800 DEOPT PACKING pc=0x00007f59fc4d44af sp=0x00007f5999cfb730 Event: 8490.174 Thread 0x00007f5a0c7f0800 DEOPT UNPACKING pc=0x00007f59efb156d3 sp=0x00007f5999cfabd0 mode 3 I noticed that we have two frames claiming to unpack to the same sp=0x00007f5999cfabd0. That doesn't sound right. I would think some assert would fail in that situation.
01-10-2019
I tried to reproduce on my Mac but am blocked by JDK-8231572. There were some changes around class initialization barriers (https://github.com/oracle/graal/commit/79d02821435b21ae54458501e0d35c005b543460) which may be relevant here.
27-09-2019
[~dlong], [~dnsimon], any known issues that would explain this?
27-09-2019
We just deoptimized the jvmci compiled method on the stack: Event: 8490.176 Thread 0x00007f5a0c7f0800 Uncommon trap: trap_request=0xffffff2f fr.pc=0x00007f59fc4c24d3 relative=0x0000000000000133 Event: 8490.176 Thread 0x00007f5a0c7f0800 Uncommon trap: reason=transfer_to_interpreter action=none pc=0x00007f59fc4c24d3 method=applications.kitchensink.process.stress.modules.ExceptionStressModule.runToString(Ljava/lang/Object;)V @ 1 jvmci Event: 8490.176 Thread 0x00007f5a0c7f0800 DEOPT PACKING pc=0x00007f59fc4c24d3 sp=0x00007f5999cfb6a0 Event: 8490.176 Thread 0x00007f5a0c7f0800 DEOPT UNPACKING pc=0x00007f59efb156d3 sp=0x00007f5999cfab58 mode 3 Most likely this is a regression introduced by the recent Graal Update (JDK-8229201). ILW = Crash due to invalid oop, with Graal as JIT and long running stress test, use different JIT = HMM = P2
27-09-2019
Latest updated included in tested build: http://hg.openjdk.java.net/jdk/jdk/rev/6df94ce3ab2f
26-09-2019