[aarch64-port-dev ] Proposed patch for C2 volatile generation (resent)
Andrew Haley
aph at redhat.com
Wed Apr 15 16:36:48 UTC 2015
Looks pretty good.
There is one remaining dmb(Assembler::SY). Please make it
dmb(Assembler::ISH).
It would be super-nice also to fix getObjectVolatile and its friends
at the same time. But you might prefer to address those with a
different patch.
compareAndSwapObject is really fugly. I would love, LOVE, to see
it fixed to use ldaxr/stlxr. :-)
I see this in ConcurrentHashMap::transfer:
0x000003ffa51f5f68: dmb ish
0x000003ffa51f5f6c: lsr x10, x0, #9
0x000003ffa51f5f70: str w17, [x0,#20]
0x000003ffa51f5f74: adrp x17, word_map_base ; {external_word}
0x000003ffa51f5f78: strb wzr, [x17,x10,lsl #0]
0x000003ffa51f5f7c: dmb ish ;*putfield val
; - java.util.concurrent.ConcurrentHashMap$Node::<init>@16 (line 628)
; - java.util.concurrent.ConcurrentHashMap::transfer at 505 (line 2452)
0x000003ffa51f5f80: dmb ish
0x000003ffa51f5f84: mov x10, x5
0x000003ffa51f5f88: lsr x17, x0, #9
0x000003ffa51f5f8c: str w10, [x0,#24]
0x000003ffa51f5f90: adrp x10, word_map_base ; {external_word}
0x000003ffa51f5f94: strb wzr, [x10,x17,lsl #0]
0x000003ffa51f5f98: dmb ish ;*putfield next
; - java.util.concurrent.ConcurrentHashMap$Node::<init>@22 (line 629)
; - java.util.concurrent.ConcurrentHashMap::transfer at 505 (line 2452)
0x000003ffa51f5f9c: dmb ish ;*aload
; - java.util.concurrent.ConcurrentHashMap::transfer at 510 (line 2447)
That does look like a lot of DMBs!
In fact, much of ConcurrentHashMap::transfer looks pretty grim. Many
redundant barriers. I think this is all to do with the mix of
Unsafe operations and volatile fields.
There's a bug in C2 where elided constructors have a memory barrier which
doesn't get elided. That bug is supposed to have been fixed, but I
can still see its effect. It's unrelated to what you're doing here,
but it does lead to a lot of mysterious DMBs.
Andrew.
More information about the aarch64-port-dev
mailing list