[kaffe] Re: Destroyed strings...
stack at cs.utah.edu
Wed Jun 5 15:42:55 PDT 2002
> Godmar wrote:
> > You're right. We can't have strings pending to be destroyed in the
> > intern table when there's a chance others might try to intern
> > identical strings. So we must synchronize against the intern lock
> > somehow, ideally without deadlocking.
> Perhaps the intern'd string table should be walked, but only the
> char objects referenced from it should be marked (not the Strings).
You could mark objects meant to be destroy()ed like objects meant to be
finalized... Also, I suppose you could just gc_add_ref() the array on
intern and gc_rm_ref() on unintern.
> (I think the intern table is currently ignored by the GC.)
> This would prevent the race conditions because the char could never
> disappear before the contianing String object did.
> I'm not sure if there's an implicit deadlock in having the GC acquire
> the string table lock...
Can we just drop the string table lock and use the gc_lock instead? They
seem to be mingling quite a bit. Would this also "solve" the nastiness
with the stringAlloc()/stringFree() functions having to unlock the
Also, how does this stuff relate to the soft/weak/phantom reference
stuff? I'm not saying we implement it now, but it seems like they would
share a some of the same problems/solutions. Just wondering aloud...
More information about the kaffe