Here are some of the desirable synchronization optimizations that I
believe are prohibited by the current CRF paper.
Consider the following program (Section 6 of the CRF paper):
synchronized(o) {
o.m1();
}
synchronized(p) {
p.m2();
}
p.m3();
Assume o and p are both thread local, and that we use the adjustment
from Figure 9. The above code is roughly equivalent to:
LocalEnter o
o.m1()
Exit o
LocalEnter p
p.m2()
Exit o
p.m3()
The CRF paper notes that this can be transformed to:
o.m1()
p.m2()
p.m3()
LocalEnter o
Exit o
LocalEnter p
Exit p
The localenter and exit statements can be moved further down the
program until they reach a real synchronization point, so the paper
claims that is almost the same as just being able to remove all
thread-local synchronization.
However, it isn't quite that simple. For this transformation to be
legal, we must be guaranteed that o.m1(), p.m2() and p.m3() cannot
possibly invoke synchronization. Particularly in the presence of
dynamic method invocation, this can be hard to prove and will make
removal of thread local synchronization very hard to perform.
In general, it appears that the CRF paper will allow
removal/collapsing of memory barriers in code that only synchronizes
on provably thread local objects. But in will not allow removal of
thread local synchronization in the vicinity of possibly non-thread
local synchronization.
Minor additional point:
There isn't any equivalent of Figure 9 for volatile variables,
although one could be added (for volatile reads). This would have the
same problem as above (not being to move potentially synchronizing
operations across thread local volatile writes).
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT