Problem with HSAIL->interpreter deopt with many variables

[Caspole, Eric]

I think I found a problem with the HSAIL deoptimization back to interpreter when there are a lot of locals in the offloaded lambda. From what I have seen so far it looks like if there are more than about 8 locals, and I am not sure what is the mix of ints and objects, when the locals get restored into the new interpreter frame in vframeArrayElement::unpack_on_stack(), it writes into the stack frame of call_stub() that is used when calling from the hsail C++ code to the x86 trampoline for the method.

I put a test case that shows working/crashing just by switching 2 lines of code at 
 http://cr.openjdk.java.net/~ecaspole/OtherArgsWithCompSafepointTest.java
Just switch the lines around at line 47 to see it work or crash.
In this test to see the crash you have to take a safepoint and deoptimize on the compiler safepoint in the loop in the kernel.
Run it with : ./mx.sh --vmbuild debug --vm server unittest -XX:+TraceGPUInteraction  hsail.test.lambda.OtherArgsWithCompSafepointTest

When the problem happens, it over writes the callee saves in call_stub so it ends up crashing in the hsail C++ code or near there.
I am not sure if this problem has always been there since we have very few test cases with this many variables.

I am not familiar with how the frames are created on a deopt. Could someone give me some hints about this? How is the newly created frame placed relative to the caller frames? How is the size of that frame determined?

Thanks,
Eric




Here is one example crash from this test case -
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fd250000770, pid=835, tid=140541751068416
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-ecaspole_2014_06_09_09_40-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.5-dev-debug mixed mode linux-amd64 )
# Problematic frame:
# v  ~StubRoutines::call_stub
#
# Core dump written. Default location: /home/ecaspole/views/graal-deopt-size/graal/core or core.835
#
# An error report file with more information is saved as:
# /home/ecaspole/views/graal-deopt-size/graal/hs_err_pid835.log
Loaded disassembler from /home/ecaspole/views/graal-deopt-size/graal/jdk1.8.0-internal/debug/jre/lib/amd64/hsdis-amd64.so
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#