aarch64 DMB - patch
adinn at redhat.com
Tue Jun 23 10:37:36 UTC 2015
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 fast_lock and fast_unlock 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
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?
More information about the hotspot-compiler-dev