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

[Robbin Ehn]

On Mon, 10 Jun 2024 05:57:04 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?

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

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