RFR: 8297036: Generalize C2 stub mechanism

Xiaolin Zheng xlinzheng at openjdk.org
Mon Nov 28 09:53:08 UTC 2022


On Wed, 16 Nov 2022 15:03:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, we have two implementations of out-of-line stubs in C2, one for safepoint poll stubs (C2SafepointPollStubTable in output.hpp) and another for nmmethod entry barriers (C2EntryBarrierStubTable in output.hpp). I will need a few more for Lilliput: One for checking lock-stack size in method prologue, one for handling lock failures (both for fast-locking), and another one for load-klass slow-path. It would be good to generalize the mechanism and consolidate the existing uses on the new general mechanism.
> 
> Testing:
>  - [x] tier1 (x86_64, x86_32, aarch64)
>  - [x] tier2 (x86_64, x86_32, aarch64)
>  - [x] tier3 (x86_64, x86_32, aarch64)

Hi Roman,

I felt there was something still vague to me, so I took another look into this issue earlier today and found another interesting thing.

It seems there are two issues reflected by this PR, but of course, this PR is only doing refactoring work... awesome.

The other issue is, it appears to me that [1] and [2] both lack a `cb->stubs()->maybe_expand_to_ensure_remaining();` before the `align()`s. After adding the expansion logic before the two places, failures are gone (on RISC-V).

So, in summary, there are two issues here (certainly, not related to this PR - this PR just interestingly triggers and lets us spot them):
1. `output()->_stub_list._stubs` is always a `0` value.
2. the missing `cb->stubs()->maybe_expand_to_ensure_remaining();` before `align()` in the shared trampoline logic, as above-mentioned.

It appears to me that we already have got the expansion logic for the two stubs [3], and the size is `2048` - enough big value to cover the sizes of the stubs.

I would like to humbly suggest some solutions to it:
1. A quick fix is to remove the `C2CodeStubList::measure_code_size()` for it always returns a `0` now (sorry for saying this), or I guess we can use some other approaches to calculate the correct node counts of the two kinds of stubs.
2. I guess I might need to file another PR to solve the missing expansion logic in shared trampolines.

I would like to hear what you think.

Best,
Xiaolin

[1] https://github.com/openjdk/jdk/blob/43d1173605128126dda0dc39ffc376b84065cc65/src/hotspot/cpu/aarch64/codeBuffer_aarch64.cpp#L55
[2] https://github.com/openjdk/jdk/blob/43d1173605128126dda0dc39ffc376b84065cc65/src/hotspot/cpu/riscv/codeBuffer_riscv.cpp#L56
[3] https://github.com/openjdk/jdk/pull/11188/files#diff-96c31ff7167c1300458cf557427ee89af5250035ecbc2f189817c793a328a502R74

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

PR: https://git.openjdk.org/jdk/pull/11188


More information about the hotspot-compiler-dev mailing list