implementing escape analysis

Boehm, Hans hans.boehm@hp.com
Thu Feb 16 20:05:00 GMT 2006


> From: Per Bothner
> 
> Stack allocating objects with finalizers is straight-forward.
> C++ has done it for decades.

Actually, C++ knows how to stack allocate objects with C++ destructors,
not Java finalizers.  Those are not at all the same thing.  

Destructors are expected to run synchronously, and usually don't acquire
locks.  If they do acquire locks, the programmer must take that into
consideration when designing the locking protocol.  They don't really
work reliably unless they are invoked at predictable and known program
points.

Finalizers are expected to run asynchronously, and generally must
acquire locks to do their job correctly.  They are expected to run in
their own thread.  If you try to run them synchronously, they tend to
deadlock.  Or corrupt data if locks are reentrant.

For details, see my POPL 2003 paper, "Destructors, Finalizers, and
Synchronization".
(http://portal.acm.org/citation.cfm?doid=604131.604153 or
http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html)

You might be able to prove that some finalizers are OK to run
synchronously.  But I think you can make a good case that all reasonable
finalizers have to update a shared data structure.  The object itself is
otherwise dead, so why bother updating it?  Thus they should either:

a) Acquire a lock on a shared data structure, or

b) End up making a system call, with the equivalent locking going on in
the kernel.

In case (a), I don't think you will generally be able to prove safety,
since you need to know that none of your possible callers could ever
hold the lock.  In case (b), you might be able to get away with it (you
can't be holding a kernel lock), but you'd probably be optimizing one of
the cheaper parts of the operation.

Thus I would suspect that by handling this case, you would get good
speedups mainly on broken code.

I would recommend just assuming that finalizable objects escape.  (As
indeed they always do, in the current implementation.)

Hans



More information about the Java mailing list