[kaffe] Re: Destroyed strings...

[Timothy Stack]

> > Also, to unintern the string you don't have to access its content
> > (or do you?)  Isn't that what Tim suggested?
> 
> Hmm... I can't see how that avoids the fundamental problem of a "live"
> object with a pointer to dead space.
> 
> 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

> I'd say this was totally and utterly broken, but it hasn't been the
> pervasive problem I would except, so I must be missing something...

well, this only applies to intern(), although i don't know how pervasive
its use is beyond string constants in classes, which are unlikely to be
freed.  It also depends on memory layouts, your changes probably moved
stuff around enough to cause problems

> 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
applies so heres a couple alternatives:

  Grab the intern lock before RESUMEWORLD() and release it after all the
  white objects have been destroyed.

  Add another call back which can be used to "disable" objects that are
  "live" from the internal perspective.

> -Pat

tim