Re: JavaMemoryModel: volatile arrays

From: David Detlefs - Sun Microsystems Labs BOS (detlefs@slats.East.Sun.COM)
Date: Thu Dec 02 1999 - 09:54:06 EST


Doug --

> Does anyone see any problem in this reasoning? If not, the memory
> model should support it.

I guess I kind of do see a problem. This "feel" a little too
operational, talking in terms of what compilers can and can't do. To
be a little clearer, you say:

    Because of the dependency on the volatile read of "data",
    the compiler is not allowed to act as if it knows anything about
    that element beforehand [*] and so cannot reuse old values.

I agree with everything before the [*] I added, but I don't see that
the conclusion after it necessarily follows. Imagine that I'm compiling

   void foo (VolatileArray va) {
     int i = va.get(0);
     int j = va.get(0);
     ...
   }

and I'm a really agressive compiler. I inline both "get"s. I
recognize that the indices are the same, and I'd like to avoid a load,
so I do:

   /* First get */
   readBarrier
   reg(d1) := data
   <bounds check, unless you're clever somehow>
   reg(i) := ld [reg(d1) + 0 + arrayHeader]

   /* Second get */
   readBarrier
   reg(d2) := data
   if (d1 == d2) {
     reg(j) := reg(i);
   } else {
     <bounds check, unless you're clever somehow>
     reg(j) := ld [reg(d2) + 0 + arrayHeader]
   }

That is, if the array reference value is the same, then I try to
re-use the previously read element value. After all, the elements
themselves are not volatile, and there has been no intervening
synchronization point. (There isn't even a killing reads issue :-)

FWIW...

Dave
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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