aarch64 DMB - patch
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 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?
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.
More information about the hotspot-compiler-dev