Jerry Schwartz writes --
> B. Consider the code
> Foo f = new Foo(...);
> f = null;
> In this case the compiler can determine that f is never accessible from
> another thread and therefore it doesn't have to actually perform the
> lock/unlock and so it doesn't need to hold onto the pointer to f. (It still
> needs to do memory barriers as appropriate, but those do not always require
> use of the pointer to f).
One thing I take from this discussion is that if "Foo" has a
"finalize" method, then it is never the case that an instance of "Foo"
is accessible only from its allocating thread. Compiler implementations
that do static analyses to determine thread-locality of allocated
objects would have to take this into account. Classes with finalizers
should be rare enough to prevent this from taking away the benefit of
such analyses, I'd think.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT