RFR: 8294729: [s390] Implement nmethod entry barriers

Lutz Schmidt lucy at openjdk.org
Wed Oct 26 20:00:39 UTC 2022


On Fri, 7 Oct 2022 14:25:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> 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 :-) )

Yes, my "optimisations" probably will be of no use because a) the compare value has. to be 4 bytes and b) the bic instruction is available from z14 only. 
Anyway, you get a glimpse of the beauty of z programming. :-)

@TheRealMDoerr Yes, z_larl() will always work within the bounds of CodeCache. But it only gives you the address where the address is stored. You need another z_lg() to get the branch address. And then there is no benefit anymore compared to two 4-byte immediate loads.

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

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


More information about the hotspot-dev mailing list