Bill Pugh wrote:
> Now, the semantics of final fields allow a compiler to move the load
> of a final field a.x to immediately after the load of a (even through
> synchronization barriers). So it is possible for i to be zero.
>
> However, the load of b.x cannot be moved to before the lock is
> acquired, so j cannot be zero.
>
> However, a compiler writer might be tempted to decide:
> * since a and b are equal
> * I can reuse the value of a.x as the value of b.x
> * getting the value 0 for j
>
> This is a slight variation on an example I posted 2/1/02. Note that
> for this example, except for the special semantics of final fields,
> it wouldn't be possible for i to be zero anyway (the synchronization
> would force a.x to be reloaded).
We want finals to not have to be reloaded within sync blocks, but to do that
we require that references to partially constructed objects not be leaked.
But we allow references to be leaked and so the requirement not to have to
reload the final field becomes a liability. Seems we have three "choices":
a) Make finals be reloaded
That's what we currently have and we consider it unacceptable.
b) Prevent references from being leaked
We can't do that.
c) Live with the consequences of not doing a) or b)
I don't have a problem with c) in the context of this example, where one
piece of code uses a good and a bad reference. But extrapolating back to the
two Runnable's example I do have a problem - as Bill originally stated,
debugging that case would be a nightmare. I think it is unconscionable that
one incorrect read of a final field could "corrupt" its value for the rest
of the program.
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:38 EDT