> From: Joshua Bloch [mailto:joshua.bloch@sun.com]
> >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.
> >
> >
> In fact, I think this is a good thing. It provides one more
> reason not
> to use finalizers.
>
But there's a fine balance here. You want to discourage people from using finalizers (or java.lang.ref) when there's another reasonable alternative. But you don't want to make finalizers so unusable that they use unreasonable alternatives instead.
(I consider any technique that basically involves reimplementing a garbage collector in client code, e.g. by reference counting, to be unreasonable. And sometimes, rarely, that's the only other option.)
Hans
-------------------------------
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