RFR: 8217874: Shenandoah: AArch64: Clobbered register in ShenandoahBarrierSetAssembler::cmpxchg_oop()

Andrew Haley aph at redhat.com
Tue Feb 12 09:53:50 UTC 2019

On 2/11/19 12:49 PM, Andrew Dinn wrote:

> That looks convincing except that the original code avoided using
> rscratch1. Was there a reason for that?
> It may be that way because the original cmpxchg code that this is
> derived from allowed that callers might be holding something in
> rscratch1 across the cmpxchg call.

If that ever was so, it was surely a bug: rscratch1 and rscratch2 are
scratch for use by assembler macros, and anyone who hopes that a macro
might preserve rscratch1 is in a state of sin. The only way to save
ourselves from nasty lurking bugs is to adhere to this rule

We have had to fix this in a few cases so that some leaf macros have
scratch registers explicitly passed in from outer macros, but we
haven't been consistent about doing so. I think we're OK, but it's all
rather fragile.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-compiler-dev mailing list