[14] RFR (M) 8231515: [Graal] Crash during exception throwing in InterpreterRuntime::resolve_invoke

[Tom Rodriguez]

Ok.  I'll add that.  Why wouldn't testing have shown this problem? 
Maybe this call path isn't currently exercised by any AOT compiled code? 
  I guess there's no sanity checking between these 2 lists of symbols 
either.

A delta webrev is at 
http://cr.openjdk.java.net/~never/8231515.delta/webrev with a full 
webrev at http://cr.openjdk.java.net/~never/8231515_2/webrev

Should I redo any of the testing?  A local build worked fine.

tom

Igor Veresov wrote on 1/21/20 4:12 PM:
> I think you need to add setting of _aot_deopt_blob_unpack_with_exception_in_tls in AOTCodeHeap::link_graal_runtime_symbols() in aotCodeHeap.cpp.
> 
> igor
> 
> 
> 
>> On Jan 17, 2020, at 1:10 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>
>> 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 changes 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 mach5 testing against jdk 14 is in progress.
>>
>> http://cr.openjdk.java.net/~never/8231515/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8231515
>