RFR: 8294729: [s390] Implement nmethod entry barriers

[Lutz Schmidt]

On Tue, 11 Oct 2022 19:03:24 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>> I think I had the same thought when I wrote the code initially, so I was doubting my reasoning. Thanks for confirming :-)
>
> After having another look at the description of `larl`, I don't think I understand why it would be a desirable replacement for `load_const`.
> 
> I replaced
> `load_const(Z_R1_scratch, StubRoutines::zarch::nmethod_entry_barrier()); ... bcr(..., Z_R1_scratch);` 
> with
> `larl(Z_R1_scratch, StubRoutines::zarch::nmethod_entry_barrier()); ... bcr(..., Z_R1_scratch);`.
> But this resulted in a bad jump since there is a mismatch between the address returned by `nmethod_entry_barrier()`, and the number of halfwords to be added to the current PC expected by `larl`. 
> 
> To make this work, it seems that I would need to compute the relative location between the current location and the address I want to jump to. Can I do this statically?

I agree: stick with the load_const as you suggested. 
You can't calculate the distance statically. The generated nmethod is copied around at least once when code generation is complete. You would need a relocation to handle that, and we don't have one. 
Sorry for all the discussion which led to just nothing.

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

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