RFR: 8332689: RISC-V: Use load instead of trampolines [v8]

[Fei Yang]

On Tue, 11 Jun 2024 11:19:50 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > > > _Mailing list message from [Andrew Haley](mailto:aph-open at littlepinkcloud.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.org):_
> > > > On 5/29/24 15:28, Robbin Ehn wrote:
> > > > > On some CPUs L1D and L1I can't contain the same cache line, which means
> > > > > the tramopline stub can bounce from L1I->L1D->L1I, which is
> > > > > expensive.
> > > > 
> > > > 
> > > > Wouldn't it be a lot easier simply to put the target address loaded by the trampoline into the constant pool?
> > > 
> > > 
> > > Seem to me that will be more cleaner than the current solution (`MacroAssembler::emit_address_stub` which uses `trampoline_stub_Relocation::spec` relocation holder but emits an 'address stub' instead of a real trampline). And I see PPC is putting the entry point as a constant into the constant pool [1] when emitting a call with trampoline stub.
> > > [1] [MacroAssembler::emit_address_stub](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/ppc/ppc.ad#L1308)
> > 
> > 
> > This was just a bit easier as I have both cases. I'll look into cp.
> > Thanks
> 
> ppc version is not possible as CP offset is stored in instruction stream. We need to use runtime_call_w_cp_type, as s390, to keep track of the offset when CP moves around during growth/relocation. It needs a bit work. What you think?

Ah, that doesn't seems to be easier than before ~. I am not familar with s390 and I didn't see where it updates the target address in CP. I will take another look at our current approach and see if there are further improvements we can do.

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

PR Comment: https://git.openjdk.org/jdk/pull/19453#issuecomment-2162327345