[kaffe] Re: Destroyed strings...

Timothy Stack stack at cs.utah.edu
Wed Jun 5 18:55:56 PDT 2002

> 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.

I think we run into the same problem as before though, we can't take the
lock before RESUMEWORLD() because it could deadlock and we can't take it
after because of the race condition.  In fact, if someone had the lock and
was looking up a string before the gc calls STOPWORLD() we'd lose

U1	hashFindSlot("FooBar");
-	thread switch "just" before it finds it, otherwise the collector
	would see the reference on the thread stack.
GC	add "FooBar" to must free
GC	lockStaticMutex(&stringLock);
-	GC blocks waiting for U1 to finish
U1	finds bogus "FooBar"

Now, the reason i brought up weak references was that they could behave

weak ref (i probably way off on how this is supposed to work):

weak ref (WR) placed on "post processing list"
WR.disable() nulls out the reference if it is white && <some other
  conditions (e.g. low mem)>
WR.destroy() puts the object on the ReferenceQueue (need to do it outside
  the RESUMEWORLD(); because someone can have the queue locked).

interned string:

interned string (IS) is white
IS.disable() nulls out the char[], preventing any matches.  As stated
  above, if the thread already found it, the collector would've traced it.
IS.destroy() removes the string from the table.

this "seems" to work, and theres no locking problem, i think...

> 	- Godmar

tim stack

More information about the kaffe mailing list