RE: JavaMemoryModel: Finalizers must be run in a finalizer thread

From: Boehm, Hans (
Date: Mon Mar 27 2000 - 12:58:50 EST

I don't think this is intentional. But it's worth mentioning. I pointed
this out once before, a long time ago, and was referred to the
java.lang.Object.finalize documentation, which stated: "It is guaranteed,
however, that the thread that invokes finalize will not be holding any
user-visible synchronization locks ..."

If I remember correctly, Guy Steele and Bill Joy agreed at the time that
this was confusing. It appears to be worse now, since the java.lang.Object
documentation is no longer in the same book.

(The fact that this was also a peristent bug in the some 1.1 VMs didn't


-----Original Message-----
From: Bill Pugh []
Sent: Sunday, March 26, 2000 7:31 AM
To:; Gilad Bracha
Subject: JavaMemoryModel: Finalizers must be run in a finalizer thread

As we've discussed, proper design of non-trival finalizers requires

However, the draft of the 2nd edition of the JLS says (Section 12.6, page

   "Also, the language does not specify which thread will invoke the

That has to be changed. Otherwise, you can't guarantee that
synchronization in the finalizer actually enforces mutual exclusion.

For example, say a system statically determined the point on which
some thread local objects became garbage, and invoked the finalizers
inline (to allow the objects to be stack allocated). Then since the
finalizers are being run in the same thread as likely holds any locks
on the objects the finalizer is locking, the locks have no effect.

I think it would be OK to just change the spec to say:

   "Finalizers are run in a thread that doesn't hold any locks at the
time the finalizers are invoked".

I think this is separate enough from the memory model issues that we
should fold it into the current JLS revision, rather than waiting for
the JMM JSR.


JavaMemoryModel mailing list -
JavaMemoryModel mailing list -

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