Re: JavaMemoryModel: Finalization idioms

From: Hans Boehm (
Date: Sun May 01 2005 - 17:55:09 EDT

On Sun, 1 May 2005, Jeremy Manson wrote:
> I guess that there are a couple of other things the user can bear in
> 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

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT