[kaffe] Re: Destroyed strings...
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
- 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 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 (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
More information about the kaffe