RFR: 8294729: [s390] Implement nmethod entry barriers [v13]

[Martin Doerr]

On Thu, 27 Oct 2022 21:06:37 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>> This draft PR implements native method barriers on s390. When complete, this will fix the build, and bring the other benefits of [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) to that platform.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up comments. Adjust copyright years.

I have to revoke my review. This does no longer look correct.

src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp line 218:

> 216: 
> 217:   // TODO: GPRS: 5 + FPRS: 8 + Flags:1?
> 218:   const int nbytes_save = (5 + 8 + 1) * BytesPerWord;

Flags are not needed.

src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp line 243:

> 241:   __ save_return_pc();
> 242:   __ push_frame_abi160(nbytes_save); // Will use Z_R0 as tmp.
> 243:   __ save_volatile_regs(Z_SP, frame::z_abi_160_size, true, true);

Adds overhead for other usages which don't need it. May be still ok, though.

src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 169:

> 167:   // Load class loader data to determine whether the method's holder is concurrently unloading.
> 168:   __ load_method_holder(Z_R0_scratch, Z_method);
> 169:   __ z_lg(Z_R0_scratch, in_bytes(InstanceKlass::class_loader_data_offset()), Z_R0_scratch);

I don't think R0 can be used for storage addressing.

src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 178:

> 176:   // Class loader is weak. Determine whether the holder is still alive.
> 177:   __ z_lg(Z_R1_scratch, in_bytes(ClassLoaderData::holder_offset()), Z_R0_scratch);
> 178:   __ resolve_weak_handle(Address(Z_R1_scratch), Z_R1_scratch, Z_R0_scratch, Z_R2);

You're killing R2 which contains the 1st argument.

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

Changes requested by mdoerr (Reviewer).

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