The motivation is there are redundant DMB instructions inserted for commonly used object allocation on aarch64 platform, for example string and Integer. In following small case:
String foo(String s)
{
String copy = new String(s);
return copy;
}
There are two dmb instructions in generated code. First one is membar_storestore, inserted in PhaseMacroExpand::expand_allocate_common. Second one is membar_release, inserted at exit of initializer method as final fields write happens. Allocated String doesn't escape in String initializer method, membar_release includes membar_storestore semantic. So first one can be removed safely.
0x0000007f85bbfa8c: prfm pstl1keep, [x11,#256]
0x0000007f85bbfa90: str xzr, [x0,#16]
0x0000007f85bbfa94: dmb ishst // first dmb to remove
....
0x0000007fa01d83c0: ldrsb w10, [x20,#20]
0x0000007fa01d83c4: ldr w12, [x20,#16]
0x0000007fa01d83c8: ldr x11, [sp,#8]
0x0000007fa01d83cc: strb w10, [x11,#20]
0x0000007fa01d83d0: str w12, [x11,#16]
0x0000007fa01d83d4: dmb ish // second dmb
String foo(String s)
{
String copy = new String(s);
return copy;
}
There are two dmb instructions in generated code. First one is membar_storestore, inserted in PhaseMacroExpand::expand_allocate_common. Second one is membar_release, inserted at exit of initializer method as final fields write happens. Allocated String doesn't escape in String initializer method, membar_release includes membar_storestore semantic. So first one can be removed safely.
0x0000007f85bbfa8c: prfm pstl1keep, [x11,#256]
0x0000007f85bbfa90: str xzr, [x0,#16]
0x0000007f85bbfa94: dmb ishst // first dmb to remove
....
0x0000007fa01d83c0: ldrsb w10, [x20,#20]
0x0000007fa01d83c4: ldr w12, [x20,#16]
0x0000007fa01d83c8: ldr x11, [sp,#8]
0x0000007fa01d83cc: strb w10, [x11,#20]
0x0000007fa01d83d0: str w12, [x11,#16]
0x0000007fa01d83d4: dmb ish // second dmb