Erik Brangs <erik.brangs@gmx.de> wrote on 02/25/2013 07:06:19 AM:
>
> The JSR-133 Cookbook [1] states under "Inserting Barriers" that special
> barriers need to be emitted for monitorexit and monitorenter. Some (or
> even all) of those can be omitted, if atomic instructions are used for
> locking and if the barriers provided by those instructions are strong
> enough.
>
> We do the monitorexit/monitorenter via ObjectModel.genericLock(..) and
> ObjectModel.genericUnlock(..) [at least in the baseline compiler]. So
> the question is really: Which barrier properties do these methods
> provide? Note that one of the required barriers is ExitEnter (=
> StoreLoad). StoreLoad barriers aren't no-ops on either IA32 or PPC.
>
>

The genericLock and genericUnlock methods of the object model are supposed to internally ensure all the memory barrier properties as required by the JMM by issuing Magic calls as needed.

For the default implementation of the object model, these methods go through the code in ThinLock.java which does a Magic.isync on successful lock acquire and Magic.sync on lock release.  The Magic names are PowerPC-centric (since they are quite old), but the intent of these magics was to generate the right memory barriers for locking/unlocking.  

Arguably the VM_Magic.sync in unlock should actually be the newer magic method Magic.fence (which is defined by the comments in Magic to be the JMM StoreLoad barrier, which is exactly what is semantically needed here).  But see below...

The baseline compiler of x86 maps sync and isync to no-ops in the generated code. It maps fence to the mfence instruction.  

However, the unlocking sequence in the ThinLock unlock methods do include a Magic.attempt (which is a locked cmpxchg) on the path when the lock is actually released.  So, I think that is actually enough to be correct although somewhat confusing (since even though we don't have a mfence, we do have a locked instruction).  It might be better to rewrite this code to be clearer (but I'm not sure if x86 implementations will make an mfence 'right after' a locked instructions 'free' or if changing the code to make it more obviously correct would incur a performance cost since there would be two StoreLoad barriers when we only need one).

--dave