> * As always, the first access of a shared object in any thread must
> perform a memory fence, or we do not even see meaningful contents
> for the object.
>
> * If we only read an object after initialization, then subsequent
> accesses need not perform memory fences on MonitorExit, and could be
> collapsed to eliminate locking entirely.
>
> I'm frankly unsure how a compiler could go about spotting the above
> properties, however---if I did I'm sure I'd also understand how to
> encode them in our framework. It would probably involve
> re-compilation after the init methods were invoked, and observing that
> those methods had become dead code.
This is not too different than class initialization -- which is the
other "synch once" construction in Java. (I mistakenly said before
that only constructors with finals were the only one).
In fact, you might argue that these rules already are or should be
present for the special case of class initialization (establishing
static final fields, vtables, etc).
And programmers can even exploit this by generating new CLASSES (not
just new objects) in initialization methods. But this would be very
ugly, slow, and completely impractical. I mention it only because it
might lead someone to think of either programming or optimization
techniques along these lines that aren't ugly, slow or impractical.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT