aarch64 DMB - patch (original) (raw)

Benedikt Wedenik benedikt.wedenik at theobroma-systems.com
Wed Jun 17 11:13:23 UTC 2015

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>

More information about the hotspot-compiler-dev mailing list