[kaffe] Re: Destroyed strings...

[Godmar Back]

> > 
> > If I have a String sitting in the hashtable that is "dead", but not
> > yet removed, how is a random thread prevented from creating a new
> > String() with the same hashcode (and maybe the same contents) and
> > coming across this string-without-chararray object in the table?
> 
> indeed, forgot about this
> 

The string with the dead char array should at this point already be 
scheduled for destruction.  So one possible way would be
to take the gc_lock and block on intern() if the mustfree is not
empty.

I think that's why it doesn't happen that often: not only does the
newly interned string have to have the same hash, but the intern
has to happen in that "small" window where the mustfree list is destroyed.
(InternHog of course opens that window wide.)

> 
> > Perhaps the destroy() function on GC objects could be run while moving
> > white objects to the mustfree list in gc-incremental.c:finishGC?  That
> > would remove the Strings from the hashtable while the world is
> > stopped, thus preventing any mutators from seeing half-dead objects in
> > the string table.
> 
> The comment in finishGC implies that this is "bad" because
> gc_heap_free() or something can block.  I don't know if this still

Well, I know that introducing the mustfree list solved a lot of
deadlock problems at the time.  

> applies so heres a couple alternatives:
> 
>   Grab the intern lock before RESUMEWORLD() and release it after all the
>   white objects have been destroyed.

That would work, except it would be a classical deadlock 
if somebody grabbed the gc_lock while holding the intern lock.
(is that possible?)

As an aside, originally, strings were uninterned in their finalizer,
but that introduced huge finalizers lists for many apps; doing it
in the destructor helped a lot of them.

A quick hack would be to destroy all strings first then the rest,
this way a string would always be destroyed before its char[] object.

Some collectors have ordered finalization for different objects 
groups for just such purposes.

	- Godmar