[11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset"
dean.long at oracle.com
dean.long at oracle.com
Mon Jul 23 18:59:14 UTC 2018
Thanks Vladimir.
dl
On 7/22/18 11:30 AM, Vladimir Kozlov wrote:
> 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
>>>>
>>
More information about the hotspot-compiler-dev
mailing list