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 : Looks like the issue mentioned by Xiaolin doesn't menifest itself when I am doing a tier1 test with release build on my linux-riscv64 platform. But I did reproduce the crash by doing a linux-riscv64 native fastdebug build. 

On how to reproduce this issue with current jdk master on linux-aarch64:

1.  Apply following small change which simply increases size of the safepointpoll stub:

diff --git a/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp b/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp
index fb36406fbde..e306bfd52ec 100644
--- a/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp
@@ -42,5 +42,8 @@ void C2SafepointPollStubTable::emit_stub_impl(MacroAssembler& masm, C2SafepointP
   __ adr(rscratch1, safepoint_pc);
   __ str(rscratch1, Address(rthread, JavaThread::saved_exception_pc_offset()));
   __ far_jump(callback_addr);
+  for (int i = 0; i < 700; i++) {
+    __ nop();
+  }
 }
 #undef __

2. Do a native fastdebug build on linux-aarch64, and the crash message looks like:

* All command lines available in /home/realfyang/openjdk-jdk/build/linux-aarch64-server-fastdebug/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/home/realfyang/openjdk-jdk/make/Init.gmk:320: main] Error 2
make: *** [/home/realfyang/openjdk-jdk/make/Init.gmk:186: images] Error 2
Building target 'images' in configuration 'linux-aarch64-server-fastdebug'
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/codeBuffer.hpp:191
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/realfyang/openjdk-jdk/src/hotspot/share/asm/codeBuffer.hpp:191), pid=3806845, tid=3806862
#  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000ffff805ffa00 <= 0x0000ffff80600434 <= 0x0000ffff80600430
#
# JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.realfyang.openjdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.realfyang.openjdk-jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x44ef48]  Instruction_aarch64::~Instruction_aarch64()+0xb0
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/realfyang/openjdk-jdk/make/hs_err_pid3806845.log
#
# Compiler replay data is saved as:
# /home/realfyang/openjdk-jdk/make/replay_pid3806845.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

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