RFR: 8299162: Refactor shared trampoline emission logic [v5]
Xiaolin Zheng
xlinzheng at openjdk.org
Mon Feb 6 06:08:36 UTC 2023
> After the quick fix [JDK-8297763](https://bugs.openjdk.org/browse/JDK-8297763), shared trampoline logic gets a bit verbose. If we can turn to batch emission of trampoline stubs, pre-calculating the total size, and pre-allocating them, then we can remove the CodeBuffer expansion checks each time and clean up the code around.
>
>
> [Stub Code]
> ...
> <shared trampoline stub1, (A):>
> __ align() // emit nothing or a 4-byte padding
> <-- (B) emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
> __ ldr()
> __ br()
> __ emit_int64()
> <shared trampoline stub2, (C):>
> __ align() // emit nothing or a 4-byte padding
> <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
> __ ldr()
> __ br()
> __ emit_int64()
> <shared trampoline stub3:>
> __ align() // emit nothing or a 4-byte padding
> <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
> __ ldr()
> __ br()
> __ emit_int64()
>
>
> Here, the `pc_at_(C) - pc_at_(B)` is the fixed length `NativeCallTrampolineStub::instruction_size`; but the `pc_at_(B) - pc_at_(A)` may be a 0 or 4, which is not a fixed-length value.
>
> So originally:
> The logic of the lambda `emit()` inside the `emit_shared_trampolines()` when emitting a shared trampoline:
>
> We are at (A) ->
> do an align() ->
> We are at (B) ->
> emit lots of relocations bound to this shared trampoline at (B) ->
> do an emit_trampoline_stub() ->
> We are at (C)
>
>
> After this patch:
>
> We are at (A) ->
> do an emit_trampoline_stub(), which contains an align() already ->
> We are at (C) directly ->
> reversely calculate the (B) address, for `pc_at_(C) - pc_at_(B)` is a fixed-length value ->
> emit lots of relocations bound to this shared trampoline at (B)
>
>
> Theoretically the same. Just a code refactoring and we can remove some checks inside and make the code clean.
>
> Tested AArch64 hotspot tier1~4 with fastdebug build twice; Tested RISC-V hotspot tier1~4 with fastdebug build on hardware once.
>
>
> Thanks,
> Xiaolin
Xiaolin Zheng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
- Merge remote-tracking branch 'github-openjdk/master' into shared-trampoline
- trampoline_stub_size() -> max_trampoline_stub_size() to reflect its semantics
- license
- Merge branch 'master' into shared-trampoline
- __
- Refactor and cleanup for shared trampolines
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/11749/files
- new: https://git.openjdk.org/jdk/pull/11749/files/8a091924..0c279f66
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=11749&range=04
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=11749&range=03-04
Stats: 9599 lines in 227 files changed: 5101 ins; 3178 del; 1320 mod
Patch: https://git.openjdk.org/jdk/pull/11749.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/11749/head:pull/11749
PR: https://git.openjdk.org/jdk/pull/11749
More information about the hotspot-dev
mailing list