Reads kill in Java, revisited

As I mentioned in a posting way back in November,
the Java memory Model prohibits certain compiler optimizations:


> 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.


Some updates:


There has been general agreement amoung a number of people, including
Guy Steele, that the Java Language Specification, as written, does
require that reads kill.


I've developed a test program that tests whether a JVM respects "Reads
kill". So far, everyone JVM I've tested either doesn't do
optimizations, or it doesn't have reads kill. In particular, the
following JVM's do not follow the spec:


Sun's 1.1.8 JVM for Wintel
Sun's 1.2.1 Classic JVM for Wintel
Sun's 1.2.1 Hotspot JVM for Wintel
IBM's 1.1.7b JVM for Wintel
Microsoft's VM for Wintel
Sun's 1.2.1 production JVM for Sparc Solaris


My test program is available from:


http://www.cs.umd.edu/~pugh/java


I've filed a bug report with Sun that their VM's don't match the spec.


Turns out there are a lot of other issues/problems with the Java memory
model. It has some other features that pretty much disable most
compiler optimizations and require memory barriers on most
architectures, even in code that has no synchronization. It also
makes lots of common programming idioms invalid. I have a
paper on this that will appear at the ACM SIGPLAN Java Grande
conference; a copy is available from the above web page.


At some point in the near future, it is likely that a Java Specification
Request will be filed to official consider changes to the Java Memory
Model. If you are interested in this issue, let me know and I will add
you to an mailing list.


Interesting side question: The SGI processor architecture
supports sequential consistency. But the SGI compilers
don't. What is the point of expending transistors to
support sequential consistency when the compiler doesn't?
Alternatively, what would be the performance impact of
disabling all compiler optimizations that violate sequential
consistency.


Prof. Bill Pugh
Dept. of Computer Science
Univ. of Maryland, College Park
http://www.cs.umd.edu/~pugh

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