RFR(S)[13]: AArch64: float point register corruption in ZBarrierSetAssembler::load_at

Stuart Monteith 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.
TemplateInterpreterGenerator::generate_fixed_frame
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.
> TemplateInterpreterGenerator::generate_fixed_frame
>
> 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 mailing list