RE: do we need separate thread for FirstThread

["Boehm, Hans" <hans_boehm at hp dot com>]

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.

The prohibition is essential.  Finalizers can, and in nontrivial cases
should, acquire locks.  If the invoking thread already holds a lock, locks
can be acquire in unexpected orders, resulting in deadlocks.  More
fundamentally, a finalizer that acquires a lock will succeed if the calling
thread already happened to hold that lock, thus effectively allowing two
operations that were supposed to run under mutual exclusion to run at the
same time.  Thus a malicious finalizer can get two copies of trusted code to
simultaneously hold the same lock.  Turning this into a security violation
is left as an exercise to the reader ...

Yes, this also does cause real programs to deadlock.

It also happens to break things with my collector.  If it weren't so
horribly broken anyway, I might consider fixing that.

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Thursday, February 08, 2001 4:58 PM
> To: Per Bothner
> Cc: Bryce McKinlay; java@gcc.gnu.org
> Subject: Re: do we need separate thread for FirstThread
> 
> 
> >>>>> "Per" == Per Bothner <per@bothner.com> writes:
> 
> Per> (2) the thread that causes gc to be invoked (by doing a new).
> Per> Why is (2) prohibited?  Do you mean as a consequence of the
> Per> boehm-gc implementation or is there some subtle point about
> Per> finalization semantics I don't know about?
> 
> I don't think it is prohibited.  But I think it is more robust to run
> finalizers in their own thread.  Otherwise you end up running
> finalizers in a thread where random, arbitrary locks might be held.
> 
> Tom
>