do we need separate thread for FirstThread

Boehm, Hans hans_boehm@hp.com
Fri Feb 9 11:44:00 GMT 2001


The usual protocol is that the GC itself enqueues finalizers.  The finalizer
thread repeatedly waits for a nonempty queue, and then runs the finalizer at
the head of the queue.  All finalizers are run sequentially.  None are run
with any locks held, unless a finalizer acquires and the fails to release a
lock.  If a finalizer blocks forever, no finalizers are ever run again.  (We
never claimed we could guard against denial of service attacks.  And no
finalizer should do this.)

I personally think this is sufficient, though we could try to be clever
about forking multiple finalizer threads.  I think it conforms to the 1.1
spec, except possibly for buggy finalizers that are not written in Java, and
fail to release a lock.  I'm not convinced that those are either a serious
issue, or handled correctly by any other JVM, unless the verifier catches it
ahead of time.

The collector already has an internal queue, and I believe nearly the
necessary hooks to implement this.  (It already needs the queue, since it's
never safe to run finalizers with the allocation lock held.  Finalizers may
allocate, after all.  Finalizers are currently run in later allocations, at
opportune times.)

Hans

> -----Original Message-----
> From: Per Bothner [ mailto:per@bothner.com ]
> Sent: Thursday, February 08, 2001 6:02 PM
> To: Boehm, Hans
> Cc: java@gcc.gnu.org
> Subject: Re: do we need separate thread for FirstThread
> 
> 
> "Boehm, Hans" <hans_boehm@hp.com> writes:
> 
> > It is prohibited.  See the description of 
> java.lang.Object.finalize: "...
> > the thread that invokes finalize will not be holding any 
> user visible locks
> > ..." .  That precludes the allocating thread.
> 
> It precludes the allocating thread, if it holds a lock.  It would also
> seem like it might preclude an existing finalizer thread.  I.e. if a
> finalizer thread is still running (I assume this is possible) when the
> next gc invocation wants to run finalizers, it may have to start a new
> finalizer thread.  So you either start a new finalizer thread each
> time you run finalizers, or if you re-use an existing thread, you
> still have to start up a new thread if the old finalizer thread is
> still running (and may have active locks).  In that case you could use
> the new-invoking thread, if you can cheaply determine that it holds no
> locks, and start a new finalizer thread otherwise.  Correct?
> (I'm not saying this would be a good thing to do ....)
> 
> In any case, I'm not (any more) proposing that we should re-use the
> allocating thread for finalizers.  Having a separate finalizer thread
> shouldn't conflict with the goal of using the initial thread as the
> Java 'main' thread.
> -- 
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/~per/
> 



More information about the Java mailing list