RFR: 8297036: Generalize C2 stub mechanism

[Roman Kennke]

On Fri, 25 Nov 2022 04:39:51 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> 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?

nmethod-barriers are not expected to be always present. It depends on the GC being active, if GC needs it, a (single) nmethod barrier is inserted. This is currently only the case for ZGC and Shenandoah. For all other GCs, nmethod barriers are not used, and thus no stubs should be emitted.

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

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