RFR(S): AArch64: float point register corruption in ZBarrierSetAssembler::load_at
stuart.monteith at linaro.org
Fri Jun 21 09:32:39 UTC 2019
Apologies - sent prematurely.
The interpreter passes rscratch1, which ultimately ends up in load_at.
The first thing you'll hit is a call from the interpreter.
888 // Get mirror and store it in the frame as GC root for this Method*
889 __ load_mirror(rscratch1, rmethod);
890 __ stp(rscratch1, zr, Address(sp, 4 * wordSize));
On Fri, 21 Jun 2019 at 10:30, Stuart Monteith
<stuart.monteith at linaro.org> wrote:
> The first thing you'll hit is a call from the interpreter.
> On Thu, 20 Jun 2019 at 18:48, Andrew Haley <aph at redhat.com> wrote:
> > On 6/20/19 5:27 PM, Stuart Monteith wrote:
> > > I see that we get a tmp1 register, however I've found that is not
> > > something we can reliably use - whether it is set to noreg or matches
> > > the src/dst registers. I've found rscratch2 to be reliably untouched.
> > > The use of scratch registers is something that needs to get fixed up
> > > on AArch64.
> > The worst abuse of AArch64 scratch registers is definitely in the
> > GC barriers. The rule is simple: scratch registers are always
> > clobbered in assembler macros. If any code calls, say, load_at() but
> > expects scratch registers to be preserved, that code is broken. We
> > need to fix it.
> > So, please tell me: where is the code which is broken by load_at()
> > using rscratch1?
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-gc-dev