[kaffe] Re: Destroyed strings...

[Godmar Back]

> > 
> > I think there was some effort to split these two locks in the
> > past... there must have been a good reason for that....  I don't know
> > if the increased contention for the lock would make any difference (or
> > the potential recursive acquires)....
> 
> 

Not that it would be very relevant in Kaffe's dog-slow silly gc
system, but I think that's the main reason.  One big master lock
would certainly solve the problem.

Another possible less intrusive idea:
Why not just hold the string intern lock while working off the
must-free list.  Take it before working off the list, release
it afterwards.

This does not lead to deadlock, because one invariant we already have
to guarantee is that no thread holding the intern lock will ever
try to get the gc_lock.  (by virtue of stringAlloc/stringFree.)
More generally, no thread must try to allocate memory while holding
any lock that is also accessed during a destroy() method call.

	- Godmar