Details
Description
The positions of static stubs / trampolines 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 inJDK-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. 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.
BTW, this is the "direct cause" of [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) because shared trampolines and there data are at the end of compiled code. Though for that issue, the root cause is still from the Binutils. Please see [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) for more details.
```
[Verified Entry Point]
...
...
...
[Stub Code]
<static stubs and trampolines>
[Exception Handler]
...
...
[Deopt Handler Code]
...
...
```
Currently after we have the shared static stubs/trampolines in
```
[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. 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.
BTW, this is the "direct cause" of [
Attachments
Issue Links
- relates to
-
JDK-8304681 compiler/sharedstubs/SharedStubToInterpTest.java fails after JDK-8304387
-
- Resolved
-