aarch64 DMB - patch

[Benedikt Wedenik]

Hi!

I did some experiments on aarch64 with specjBB2005 and other benchmarks and I found out,
that not emitting memory barriers (DMB) in c2 (see attached patch) improved the performance
by about 7%. The runs were still valid.

I wrote a micro-benchmark (attachment), which only deals with synchronization,
because the memory barriers (DMB) are emitted in the synchronized methods.
I had a look into the generated assembly and I found out, 
that all needed variables are loaded and stored by using instructions
like ldaxr / stlxr. As far as I knew these functions already guarentee an
exclusive, as well as ordered access, which would be forced by the
(redundant) DMB instruction.

To be sure I did some research in the unified ARMv8 spec and found some interesting statements.
In chapter B2.7 Memory ordering, Load-Acquire Store-Release (page 88-89) one can read the following:

page 88:
There are no additional ordering requirements on loads or stores that appear before the Load-Acquire. 
There are no additional ordering requirements on loads or stores that appear in program order after the Store-Release. 

page 89:
The Load-Acquire/Store-Release instructions can remove the requirement to use the explicit DMB memory barrier instruction. 


This tells me, that my patch does not touch the correctness of the generated code but increases the performance.


Benedikt



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aarch64.ad.patch
Type: application/octet-stream
Size: 575 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/aarch64.ad.patch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi.java
Type: application/octet-stream
Size: 577 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/Multi.java>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Worker.java
Type: application/octet-stream
Size: 169 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/Worker.java>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/5c3684e6/attachment-0003.html>