RFR: 8297036: Generalize C2 stub mechanism

[Fei Yang]

On Fri, 25 Nov 2022 10:43:30 GMT, Roman Kennke <rkennke 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?
>> 
>> Best,
>> Xiaolin
>
>> 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.

@rkennke @zhengxiaolinX : Please ignore my previous message. I think change increases the size of the safepointpoll stub too much and thus breaks the condition at [1]. So false alarm. 

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/output.cpp#L233

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

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