Reads kill in Java

    Consider the following code fragment, where p and q might be aliased:


i = p.x;
// potential concurrent write to p.x here
j = q.x;
k = p.x;


    Note that no synchronization occurs in this fragment.


    If it happens that p and q are in fact aliased, and the read of q.x
gets the new value of p.x, my understanding of the infamous chapter 17
of the Java Language Specification is that the second read of p.x must
get the new value as well. It is certainly surprising (to someone not
familiar with data races) if the second read of p.x gets the old
value. Therefore, we can't replace the second load of p.x with the
value we got from the first load.


    Note that if the read of q.x had not been present, then it would be
perfectly fine for the second read of p.x to access either the old or
the new value.


    The upshot of this would seem to be that you need to treat a
potentially aliased read as being a kill of the load (essentially, it
might force your thread to become aware of a change by another
thread).


    For similar reasons, you could not reorder the loads of p.x and q.x.


    A number of people writing optimizing compilers for Java said that
they had not thought of this issue and don't have reads kill in their
compiler.


    I've discussed this with Guy Steel and Doug Lea. We went back and
forth a few times, but at the end of OOPSLA, we seemed to be in
relative agreement that reads kill, according to the Java Language
Spec 1.0. However, it isn't too important what the spec requires,
since the JLS is being revised, and chapter 17 is being rewritten from
scratch. What needs to be decided is whether we want:
* Ugly semantics in the face of data races, or
* Ugly effects on compiler optimizations
If anyone could put together some numbers on the performance impact of
having all reads kill, that would be very helpful in making this
decision. Send them to me or to Guy Steel.


    This isn't really a Java issue. This issue arises in any language
that attempts to give clean semantics to programs with data
races. However, as far as I know, Java is the only language to try to
do so.


Bill Pugh

Return to the comp.compilers page.
Search the comp.compilers archives again.