RFR: 8304387: Fix positions of shared static stubs / trampolines [v2]

[Fei Yang]

On Mon, 20 Mar 2023 12:08:16 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> This RFE fixes the positions of shared static stubs / trampolines. They should be like:
>> 
>> 
>> [Verified Entry Point]
>>     ...
>>     ...
>>     ...
>> [Stub Code]
>>     <static stubs and trampolines>
>> [Exception Handler]
>>     ...
>>     ...
>> [Deopt Handler Code]
>>     ...
>>     ...
>> 
>> 
>> Currently after we have the shared static stubs/trampolines in JDK-8280481 and JDK-8280152 :
>> 
>> 
>> [Verified Entry Point]
>>     ...
>>     ...
>>     ...
>> [Stub Code]
>>     <static stubs and trampolines>
>> [Exception Handler]
>>     ...
>>     ...
>> [Deopt Handler Code]
>>     ...
>>     ...
>>     <shared static stubs and trampolines> // they are presented in the Deopt range, though do not have correctness issues.
>> 
>> 
>> For example on x86:
>> 
>> 
>> [Verified Entry Point]
>>   ...
>> [Stub Code]
>>   0x00007fac68ef4908:   nopl   0x0(%rax,%rax,1)             ;   {no_reloc}
>>   0x00007fac68ef490d:   mov    $0x0,%rbx                    ;   {static_stub}
>>   0x00007fac68ef4917:   jmpq   0x00007fac68ef4917           ;   {runtime_call}
>>   0x00007fac68ef491c:   nop
>>   0x00007fac68ef491d:   mov    $0x0,%rbx                    ;   {static_stub}
>>   0x00007fac68ef4927:   jmpq   0x00007fac68ef4927           ;   {runtime_call}
>> [Exception Handler]
>>   0x00007fac68ef492c:   callq  0x00007fac703da280           ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>>   0x00007fac68ef4931:   mov    $0x7fac885d8067,%rdi         ;   {external_word}
>>   0x00007fac68ef493b:   and    $0xfffffffffffffff0,%rsp
>>   0x00007fac68ef493f:   callq  0x00007fac881e9900           ;   {runtime_call MacroAssembler::debug64(char*, long, long*)}
>>   0x00007fac68ef4944:   hlt
>> [Deopt Handler Code]
>>   0x00007fac68ef4945:   mov    $0x7fac68ef4945,%r10         ;   {section_word}
>>   0x00007fac68ef494f:   push   %r10
>>   0x00007fac68ef4951:   jmpq   0x00007fac70326520           ;   {runtime_call DeoptimizationBlob}
>>   0x00007fac68ef4956:   mov    $0x0,%rbx                    ;   {static_stub}       //  <----------  here
>>   0x00007fac68ef4960:   jmpq   0x00007fac68ef4960           ;   {runtime_call}
>>   0x00007fac68ef4965:   mov    $0x0,%rbx                    ;   {static_stub}       //  <----------  here
>>   0x00007fac68ef496f:   jmpq   0x00007fac68ef496f           ;   {runtime_call}
>>   0x00007fac68ef4974:   mov    $0x0,%rbx                    ;   {static_stub}       //  <----------  here
>>   0x00007fac68ef497e:   jmpq   0x00007fac68ef497e           ;   {runtime_call}
>>   0x00007fac68ef4983:   hlt
>>   0x00007fac68ef4984:   hlt
>>   0x00007fac68ef4985:   hlt
>>   0x00007fac68ef4986:   hlt
>>   0x00007fac68ef4987:   hlt
>> --------------------------------------------------------------------------------
>> [/Disassembly]
>> 
>> 
>> 
>> It can be simply reproduced and dumped by `-XX:+PrintAssembly`.
>> 
>> Though the correctness doesn't get affected in the current case, we may need to move them to a better place, back into the `[Stub Code]`, which might be more reasonable and unified. Also for the performance's sake, `ciEnv::register_method()`, where `code_buffer->finalize_stubs()` locates currently, has two locks `Compile_lock` and `MethodCompileQueue_lock`. So I think it may be better to move `code_buffer->finalize_stubs()` out to C1 and C2 code generation phases, separately, before the exception handler code is emitted so they are inside the `[Stub Code]` range.
>> 
>> BTW, this is the "direct cause" of [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) because shared trampolines and their data are generated at the end of compiled code, which is different from the original condition. Though for that issue, the root cause is still from the Binutils, for even if trampolines are generated at the end of code, we should not fail as well when disassembling. But that is another issue, please see [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) for more details.
>> 
>> Tested x86, AArch64, and RISC-V hotspot tier1~4 with fastdebug build, no new errors found.
>> 
>> Thanks,
>> Xiaolin
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Andrew's review comments: another cleanup

LGTM.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13071#pullrequestreview-1349793484