[aarch64-port-dev ] volatiles and membars in jdk7 aarch64.ad
Andrew Haley
aph at redhat.com
Tue Nov 25 18:26:52 UTC 2014
On 11/25/2014 04:59 PM, Andrew Dinn wrote:
> When I first backported the aarch64.ad rules to JDK7 I deleted all the
> special case volatile load/store rules, removed the 'treat_as_volatile'
> predicates from the normal case load/store rules and relied on the
> membar rules to ensure synchronization occurs where needed. That was
> because the non-volatile case was isolated through the use of predicates
> which called treat_as_volatile() and the latter relies on being able to
> call memnode->is_volatile(). JDK7 has no such method.
>
> While modifying JDK7 to add the pipeline model I noticed that the latest
> jdk8 aarch64.ad relies on predicates which call memnode->is_unordered()
> to isolate the non-volatile cases. Now, JDK7 /does/ include this method.
> It might, therefore, be appropriate to rejig the jdk7 rule set to
> re-include the volatile rules (i.e. ruels which use load acquire and
> store release) and reinstate a predicate for the normal case load/store
> rules based on is_unordered(). However, I am not sure about what this
> implies for the membar rules or, perhaps more germane, for the shared
> code which generates the required membar operations.
>
> What has been done to jdk8 to avoid generating memory barriers for
> volatile operations. Are there any shared code changes I would need to
> backport in order to ensure that we don't end up executing unnecessary
> memory barriers for cases where we would also end up using a load
> acquire or store release?
>
> Is it a good idea to try this?
This really is in flux at the moment. I have a patch nearly ready
which switches on the command line, so we can do some benchmarking.
I'd stay with separate barriers for now.
Andrew.
More information about the aarch64-port-dev
mailing list