[kaffe] Re: Destroyed strings...

[Timothy Stack]

> > > 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...  
> 
> I don't think this would work because the char[] could be gone before
> the String object is moved to the finalizer list...  The only thing
> keeping the char[] alive is the live String reference.

Right, marking the string implies that it would recursively mark the
array.  With some shuffling of the lists you could probably automagically
implement the dependencies here, anything added to the grey/black list at
this point would be swept after these objects.

> > Also, I suppose you could just gc_add_ref() the array on intern and
> > gc_rm_ref() on unintern.
> 
> I don't think the unintern would ever get called because the String
> would always have a reference.  This would solve the problem, but fill
> the string table with unused intern'd strings.  :)

er, gc_add_ref() _the array_ (i.e. gc_add_ref(string->value);), not the
string object, thats what you proposed! :)

> > 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.
> 
> I think there was some effort to split these two locks in the
> past... there must have been a good reason for that....  I don't know
> if the increased contention for the lock would make any difference (or
> the potential recursive acquires)....

bah, the log gives no clues...

> -Pat

tim stack