Re: JavaMemoryModel: Indirect loads and processor consistency

From: Doug Lea (dl@cs.oswego.edu)
Date: Tue Dec 03 2002 - 20:46:54 EST


Thanks Tim and Kourosh. I'll revise cookbook draft.

Some other notes while I'm at it:

1. Allan Kielstra of IBM kindly verified that powerpc's work in the
right way wrt indirection. (The Book-E spec also has a sentence
implying this in appendix D.) So, of the processors in my list, we
are still waiting for something more defintive about x86-SPO, but
otherwise the alpha is the only known processor that may require
barriers on reads of references that may hold final fields (or use
one of Bill's suggestions in:
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0180.html)

3. BTW, note that in Java, a more realistic version of the main
example would also have a control dependency:

     Initially, a == null, x == 0
 
     Thread 1 Thread 2
     x = 1 r1 = a
     StoreStoreBarrier if (r1 == null) goto throwNullPtrExc
     a = &x r2 = *r1
 
     Can r1 == a && r2 == 0?
 
But from Kourosh's description, this would still not always work on alpha.

3. I just noticed that on any processor that does provide ordering on
indirection and/or control, you can sometimes optimize away some other
barriers mentioned in cookbook. Cool.

4. I found a section in the Book-E enhanced powerpc spec indicating
that stores can pass loads, so it apparently DOES need a form of
LoadStore barrier. (So, yet more more cookbook revisions...)
Interestingly enough, the suggested way to implement them is not by a
barrier instruction, but by introducing a control dependence that
never actually fires:

    r1 = x
    if (r1 != r1) goto fin
    y = r2
  fin:

(See the Book E- Enhanced PowerPC Architecture manual, page 400.)

5. The whole issue about whether and how indirection and control
dependencies interact with ordering and barriers is pretty murky, with
the execption of ia64 and sparcV9 specs, that both specifically
address it. I hope that in the future, processor specs routinely cover
this issue since it can make a big difference in performance.
(And being explicit would lead to less frustration for those of us
trying to figure out how they mesh with language semantics.)

-- 
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/  
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:41 EDT