aarch64: C2 fast lock/unlock issues
aph at redhat.com
Wed Sep 2 17:22:58 UTC 2015
I've been tracing through the bias revocation code and I'm now happy
that the problem I imagined with this patch and biased locking is OK.
The reason that it's OK to execute a synchronized block with no memory
fences at all is rather subtle. However, I think you are right: as
long as biased locking is correct, this is correct too.
[If anyone is interested, the argument is this: the thread holding the
bias does not ever execute a fence instruction, so it may never see
any other thread's writes, and no other thread will see its writes.
Say another thread tries to acquire the lock, and so has to revoke the
bias. It will bring the holder to a safepoint, at which point the
biased lock will be turned into a normal fast lock, and it will resume
Also, there is no need to make any memory access inside the
synchronized region visible to any other thread (which does not
acquire the lock) because there is no happens-before relationship
between such an access and any other thread.
So, even though a biased lock is being acquired and released, there is
no need for any memory fences.]
I'm running some tests.
More information about the hotspot-compiler-dev