On Sun, 1 May 2005, Jeremy Manson wrote:
> I guess that there are a couple of other things the user can bear in
mind:
>
> 1) For many of the use cases of finalizers (I/O classes, for example),
> the cost of performing a keepAlive (in any form, whether it be
> volatiles, writing a reference to the heap, or empty synchronization) is
> swamped by the cost of actually performing the task.
That's certainly what I would hope.
For now I decided to put in keepAlive() calls to a local method,
and to impliment those with an empty synchronized function.
I put an empty synchronized block in the finalizer.
That's textually not too ugly. And it makes it eassy to swap
in a different implementation.
>
> 2) If performance is critical, the programmer can limit the invocations
> of keepAlive to the client code; thus, in the cases where you don't need
> keepAlive (all those in which a reference to the object is written out
> to the heap), it doesn't get called.
>
> This second thing may not be good for many libraries, but there are few
> enough of them with finalizers that it may work.
I hope that generally won't be necessary.
The current treatment of finalizers is clearly suboptimal for programmer
convenience. On the other hand, I'm not convinced that adding pervasive
compiler overhead for a rarely used feature would have been a better
solution.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT