[kaffe] Re: Destroyed strings...

[Timothy Stack]

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

U1	hashFindSlot("FooBar");
-	thread switch "just" before it finds it, otherwise the collector
	would see the reference on the thread stack.
GC	STOPWORLD();
GC	add "FooBar" to must free
GC	RESUMEWORLD();
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
similarly:

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

STOPWORLD();
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)>
RESUMEWORLD();
WR.destroy() puts the object on the ReferenceQueue (need to do it outside
  the RESUMEWORLD(); because someone can have the queue locked).


interned string:

STOPWORLD();
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.
RESUMEWORLD();
IS.destroy() removes the string from the table.


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

> 	- Godmar

tim stack