[11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset"

[Vladimir Kozlov]

Thank you for explanation, Dean.

Reviewed. Good.

Vladimir

On 7/22/18 11:22 AM, dean.long at oracle.com wrote:
> On 7/22/18 10:28 AM, Vladimir Kozlov wrote:
>> Dean,
>>
>> On 7/21/18 9:57 PM, dean.long at oracle.com wrote:
>>> On 7/21/18 5:37 PM, Vladimir Kozlov wrote:
>>>> To be clear. We don't use far call for AOT because in AOT code we 
>>>> call through trampoline anyway. Right?
>>>
>>> Yes, we call through a "PLT".
>>>
>>>>
>>>> My question is do we do that for all calls? Or only runtime calls?
>>>>
>>>
>>> I believe we call through the PLT for everything except calls to code 
>>> that we know is in the AOT library, like Graal-generated stubs.
>>> This is a direct call:
>>
>> Sorry, I was not clear. I asked about code generated by Graal JIT not 
>> for AOT. Your changes seem generate indirect call in all cases when 
>> scratch register is specified:
>>
>> if (scratch != null && !GeneratePIC.getValue(crb.getOptions())) {
>>
> 
> Yes, and that was also the old behavior.  The new changes are:
> 1) to disallow using the scratch register for AOT calls
> 2) allowing directJmp to make a far jump
> 3) using a scratch register for far calls to foreign functions 
> ENABLE_STACK_RESERVED_ZONE and THROW_DELAYED_STACKOVERFLOW_ERROR. Other 
> calls are left unchanged.
>> What about calls from nmethod to nmethod? They should not be far 
>> calls. I am not familiar with Graal and that is why I am asking.
>>
> 
> For Java invokes, they can be direct or indirect.  For direct invokes on 
> x64, Graal is using near calls with a null scratch register.
> 
> http://hg.openjdk.java.net/jdk/jdk11/file/d5138f8da1ba/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Call.java#l104 
> 
> 
> dl
> 
>> Thanks,
>> Vladimir
>>
>>>
>>>      2883:       e8 98 1a 00 00          callq  4320 
>>> <Stub<ExceptionHandlerStub.exceptionHandler>>
>>>
>>> This calls through a PLT:
>>>
>>>      2c17:       e8 b4 15 00 00          callq  41d0 
>>> <M1_759_java.lang.invoke.MethodHandle.asType(Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MethodHandle;_plt.entry> 
>>>
>>>
>>> Finally, we use trampolines when an nmethod needs to make a far call 
>>> to AOT code.
>>>
>>> dl
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/21/18 11:52 AM, dean.long at oracle.com wrote:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8207383
>>>>> http://cr.openjdk.java.net/~dlong/8207383/webrev/
>>>>>
>>>>> This fixes a regression caused by JDK-8181855.  The fix is to use a 
>>>>> scratch register to make far calls, but force a near call for AOT.
>>>>>
>>>>> Changeset based on contribution by Tom Rodriguez.
>>>>>
>>>>> dl
>>>
>