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

[Vladimir Kozlov]

On 1/22/20 9:45 AM, Tom Rodriguez wrote:
> 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

Good.

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

Sync with latest JDK 14 and run tier1 - it will run AOT tests too. I think it should be enough for this incremental change.

Thanks,
Vladimir

PS: testing results you got are good.

> 
> 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
>>