aarch64 DMB - patch (original) (raw)

Andrew Haley aph at redhat.com
Tue Jun 23 14:32:09 UTC 2015

On 06/23/2015 11:37 AM, Andrew Dinn wrote:

On 23/06/15 11:28, Andrew Haley wrote:

On 23/06/15 11:12, Andrew Dinn wrote:

However, I am not convinced that these barriers can be removed even granted that change. There are various other memory operations encoded in both the fastlock and fastunlock cases both before and after the load-exclusive + store-exclusive pair. I believe the point of separating out the MemBarAcquireLock and MemBarReleaseLock from FastLock and FastUnlock is to ensure that those related memory operations are correctly synchronized wrt to memory operations performed by other threads which may be trying to synchronize on the same oop.

It's delicate code, for sure. For a while we weren't using stlxr when acquiring a lock because I decided we didn't need to. This was wrong because when you copy a header word to the displaced header you must ensure that the store to the displaced header itself happens-before the store of the pointer to the displaced header. OTOH, I'm not at all sure we need the separate locks as well as LDAXR/STLXR. Sorry, not sure I fully grokked that. Do you mean "I'm not at all sure we need the separate dmbs as well as the LDAXR/STLXR"? Or are you talking about something else?

Very sorry. Yes, I mean to say that I'm not at all sure we need the separate dmbs as well as the LDAXR/STLXR.

Andrew.

More information about the hotspot-compiler-dev mailing list