RFR: 8297036: Generalize C2 stub mechanism

[Xiaolin Zheng]

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,

Sorry for the late response - It is the former.

> Are you saying that in init_buffer(), we don't have any method_entry_barrier stubs, yet, and therefore we return 0 there?

This one. That `output()->_stub_list._stubs` appears to me to be always zero, for nodes are not emitted yet. I confirmed that before this patch `_safepoint_poll_table` is `0` but `_entry_barrier_table` is a non-zero value, like on aarch64 is `24`. Why it can work before is I think it is within some margins of error. Like `code_req += MAX_inst_size;    // ensure per-instruction margin`, RISC-V's generated code is more verbose, so reproduces this. Simply adding a `4`, which is just one instruction size, to the new `stub_req` can make the build pass.

But the zero value of `_stub_list._stubs` is not an expectant one, though - I am not quite sure the best way to fix that. The table sizes are in fact both 1 to me?

Best,
Xiaolin

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

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