RFR 8209626: [JVMCI] Use implicit exception table for dispatch and printing

[Vladimir Kozlov]

On 5/31/19 1:41 PM, Tom Rodriguez wrote:
> Updated webrev at http://cr.openjdk.java.net/~never/8209626.1/webrev

Looks good.

> 
> Vladimir Kozlov wrote on 5/30/19 11:55 AM:
>> Hi Tom,
>>
>> Can you add comment to next new code that it is to support old JVMCI? Otherwise it is confusing because in JDK repo we 
>> will not have the issue:
>>
>> getDeclaredMethod("implicitExceptionTable");
> 
> I added a comment and also added a check that it's required starting with JDK13.  The mach5 job is in progress.
> 

Okay.

>>
>> In jvmci/jvmciRuntime.hpp spacing is not aligned with the rest of arguments.
> 
> Fixed.
> 
>>
>> The rest seems fine.  what testing you did with new code?
> 
> The existing graal tests should exercise the new implicit exception dispatch path adequately and I manually inspected 
> the PrintNMethods output.  The JDK8 version of this code has been in use for many months. A sample of the disassembly is 
> below:
> 
>    0x00000001230c3a07:   mov    r10d,DWORD PTR [rax*8+0xc]
>    ; implicit exception: deoptimizes
>    ; ImmutableOopMap {rax=NarrowOop rsi=Oop }
> 
> 
> By the way the new PrintNMethods default output seems awful.  No comments at all by default and the labels marking the 
> Entry Point seem to be totally disconnected.  The alignment is kind of screwy too.
> 
>    0x00000001230c3a12:   jle    0x00000001230c3a5a
> ;*if_icmplt {reexecute=0 rethrow=0 return_oop=0}
> ; - java.lang.StringLatin1::charAt at 7 (line 47)
> ; - java.lang.String::charAt at 12 (line 708)
>    0x00000001230c3a18:   cmp    r10d,edx

Strange, Lutz fixed output recently for 8213084. Can you try PrintAssembly instead? May his changes affect PrintNMethods 
in wrong way.

Thanks,
Vladimir

> 
> tom
> 
>>
>> Thanks,
>> Vladimir
>>
>> On 5/30/19 11:27 AM, Tom Rodriguez wrote:
>>> I have updated this webrev to include fixes to AOT to properly capture the implicit exception table and record the 
>>> offset for it in the AOT binary.  It required minor Graal changes which I will push upstream separately.  Please 
>>> rereview.
>>>
>>> tom
>>>
>>> Tom Rodriguez wrote on 12/12/18 11:22 PM:
>>>>
>>>>
>>>> Vladimir Kozlov wrote on 12/12/18 2:29 PM:
>>>>> On 12/12/18 1:06 PM, Tom Rodriguez wrote:
>>>>>> They all look like preexisting failures to me.  The CheckGraalIntrinsics one you mentioned in chat and 
>>>>>
>>>>> yes
>>>>>
>>>>>> compiler/aot/DeoptimizationTest.java which seems to have been failing at least intermittently for a while.  What 
>>>>>> do you think?
>>>>>
>>>>> SIGFPE is new. And I think your changes in sharedRuntime.cpp may affected execution of AOT methods because they are 
>>>>> marked as compiled by Graal (compiler_jvmci):
>>>>>
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/9e28eff3d40f/src/hotspot/share/aot/aotCompiledMethod.hpp#l131 
>>>>
>>>>
>>>>
>>>> Yes I think I need to move some code around to properly support AOT. I'll send out an updated webrev soon but I 
>>>> think we can defer this one until jdk 13.
>>>>
>>>> tom
>>>>
>>>>>
>>>>>
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>> It does make me wonder if AOT needs any extra support to use the implicit exception table.  I would assume we'd be 
>>>>>> seeing problems if that was the case but don't really know.
>>>>>>
>>>>>> tom
>>>>>>
>>>>>> Vladimir Kozlov wrote on 12/12/18 11:12 AM:
>>>>>>> Tom,
>>>>>>>
>>>>>>> Some tests failed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 12/12/18 10:42 AM, Tom Rodriguez wrote:
>>>>>>>> http://cr.openjdk.java.net/~never/8209626/webrev
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209626
>>>>>>>>
>>>>>>>> Graal handles implicit exceptions by deoptimizing and that's currently done in a way that's hard to understand 
>>>>>>>> from the PrintNMethods output. Basically there's just an extra PcDesc at the implicit check location and the 
>>>>>>>> runtime assumes that a fault with a PcDesc underneath it an implicit check.  This changes JVMCI to use the 
>>>>>>>> implicit exception table to mark these locations specially which simplifies the dispatching and 
>>>>>>>> printing.  The new print output looks like this:
>>>>>>>>
>>>>>>>>    0x0000000120f053a0: mov    DWORD PTR [rsp-0x14000],eax
>>>>>>>>    0x0000000120f053a7: sub    rsp,0x18
>>>>>>>>    0x0000000120f053ab: mov    QWORD PTR [rsp+0x10],rbp ;*aload_0 {reexecute=1 rethrow=0 return_oop=0}
>>>>>>>>                                                              ; - java.lang.StringLatin1::equals at 0 (line 94)
>>>>>>>>
>>>>>>>>    0x0000000120f053b0: mov    eax,DWORD PTR [rsi+0xc]        ; implicit exception: deoptimizes
>>>>>>>>                                                              ; ImmutableOopMap{rdx=Oop rsi=Oop }
>>>>>>>> ;*aload_0 {reexecute=1 rethrow=0 return_oop=0}
>>>>>>>>                                                              ; - java.lang.StringLatin1::equals at 0 (line 94)
>>>>>>>>
>>>>>>>>    0x0000000120f053b3: mov    r10d,DWORD PTR [rdx+0xc]       ; implicit exception: deoptimizes
>>>>>>>>                                                              ; ImmutableOopMap{rdx=Oop rsi=Oop }
>>>>>>>>
>>>>>>>> The scope information is still printed in the normal original location. This has been in use with JVMCI 8 for 
>>>>>>>> several months.
>>>>>>>>
>>>>>>>> tom