[aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector

[Liu Xin]

hi, Andrew and Martin,

Thanks you to review my patch. I trace the feature UseCondCardMark. It was
introduced by the following changes.
https://bugs.openjdk.java.net/browse/JDK-8076987 C1
https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter
UseCondCardMark is only supported by C2 currently. Yes, my original patch
does miss hunk -- the x86 part. That's why I propose a new webrev here.
It's almost a clean backport for JDK-8135018.  Let's solve the missing
barrier bug first. Could you take a look at it?
https://cr.openjdk.java.net/~xliu/8135018/01/webrev/

I have verified it using hotspot:tier1 on aarch64.
I also eyeballed the generated code. If -XX:+UseConcMarkSweepGC is present,
the membar(StoreStore)  is inserted as expected.

  0x0000ffff7c317f58: lsr       x0, x1, #9
  0x0000ffff7c317f5c: mov       x1, #0xd000                     // #53248
  0x0000ffff7c317f60: movk      x1, #0x4fdf, lsl #16
  0x0000ffff7c317f64: movk      x1, #0xffff, lsl #32
  0x0000ffff7c317f68: dmb       ishst
  0x0000ffff7c317f6c: strb      wzr, [x0, x1, lsl #0]  ;*putfield arr
                                                ; - ByteTest::actor1 at 4
(line 5)

thanks,
--lx



On Fri, Dec 13, 2019 at 7:21 AM Andrew Haley <aph at redhat.com> wrote:

> On 12/13/19 1:38 PM, Doerr, Martin wrote:
> > I guess the change would apply cleanly on top of
> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a179f93d775
> >
> > If it's easy to backport (I haven't tried) doing that one first should
> be the preferred way.
> >
> > But if that change is not wanted in 8u, I'll be fine with Ix's version.
> > Having the UseCondCardMark code only at some places wouldn't break
> anything. There's no consistency requirement.
>
> OK, but I'm trying to understand what is going on. Either UseCondCardMark
> is
> supported by AArch64 in JDK 8 or it is not. If it is not, then all we have
> to do is insert any missing memory barriers. If it's supposed to be, then
> we should be consistent.
>
> --
> Andrew Haley  (he/him)
> 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
>
>