Re: JavaMemoryModel: Issue with final fields

From: Bill Pugh (
Date: Sat Feb 02 2002 - 07:11:24 EST

At 9:54 AM -0800 2/1/02, Cliff Click wrote:
>Bill Pugh wrote:
>Yes it bothers me, but not a lot. You published a bogus Foo. Anything
>that touches this bogus Foo is now Bogified (TM). You and your program
>will be shot at dawn. :-)

No, you've got it reversed. Under the current version of our
semantics, the compiler would not be able to perform that
optimization. If a thread loads both a proper reference to a Foo and
a Bogified reference to that same Foo, the Bogified reference does
_not_ taint the proper reference to the Foo.

The alternative would be to do it on a thread basis. To say that if a
thread T has loaded an improperly published reference to an object X,
all final fields of X are make pseudo-final for all accesses by
thread T, no matter which reference is used to access X.

In addition to requiring us to change our semantics, this thread
contamination has a number of unfortunate effects:

* adding an unused read isn't idempotent. Right now, if you take a correctly
   synchronized program and add some incorrectly synchronized reads (perhaps
   for debugging purposes), the original reads/writes are not effected
   by the additional reads.

* Datarace bugs aren't local. Some piece of code that you have no
relation to or
   interaction with may have loaded the Bogified reference to Foo. Now your
   code, even though it always using properly published references to Foo's,
   is tainted.

So I'm not thrilled by the fact that the compiler will be constrained
to avoid the transformation I showed earlier, I think it is better
than allowing the transformation and having a model which makes it
harder to write reliable multithreaded software.

JavaMemoryModel mailing list -

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