[kaffe] Re: Destroyed strings...

[Timothy Stack]

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

it is

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

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

> -Pat

tim