RFR: 8294729: [s390] Implement nmethod entry barriers

[Martin Doerr]

On Fri, 7 Oct 2022 14:11:42 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>> Edit: adapted to the fact that entry_barrier is an 8-byte field with only the rightmost 4 bytes being significant.
>> 
>> If this isn't nerdy enough, I have another idea (**works only on z14 and newer**). It replaces the load_const at the beginning with a z_larl() and then uses a z_bic() to fetch the target address and branch there. The z_larl will never go out of range because all generated code is in the code cache which is limited to 4GB in size. In total we would get: 
>> 
>> __ z_larl(Z_R1_scratch, &StubRoutines::zarch::nmethod_entry_barrier());
>> __ z_clghsi(in_bytes(bs_nm->thread_disarmed_offset()), Z_thread, /* to be patched */ -1);
>> __ z_larl(Z_R14, (instr_len((unsigned long)LARL_ZOPC) + instr_len((unsigned long)BIC_ZOPC)) / 2);
>> __ z_bic(Assembler::bcondNotEqual, 0, Z_R0, Z_R1_scratch);
>> 
>> Nice, short, compact.
>
> Well spotted. I hadn't appreciated that this instruction wasn't setting the return address.
> 
> I am leaning towards the first ~nerdy~ cool hack if it's more general, though I do appreciate the compactness of the second suggestion.

Doesn't `z_larl(Z_R1_scratch, &StubRoutines::zarch::nmethod_entry_barrier())` always work? It uses a relocation and can reach any address within the code cache. I think this makes sense regardless of the z14 choice. (Note that there are complicated offset computations and processor model dependent code won't make it easier :-) )

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

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