Re: patch for gc of interned String

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Per Bothner wrote:

> That is ok - but what is not ok was that
> when an interned String is collected, there is nothing to
> remove it from the intern table - the code that does so is
> commented out ...  Ooops.

Yep. We've known about this for a long time...

> Does this look like a reasonable fix?  I especially would
> like Hans's opinion, of course.  Basically we want the
> intern table to be a "weak set", and this seems like a simple
> way to do so, but it depends on the cost of finalizers.

The basic problem with this approach is that it fails when an intern() call for a
different string with the same value is made after the GC finds the interned
string to be unreachable but before the finalizer is run. In that case, the
finalizer will accidentally clear a pointer to a reachable, interned string.
Another problem is that in pedantic test cases which rapidly intern a lot of
strings and forget about them, its theoretically possible to end up with long
chains of DELETED_STRING pointers, potentially even enough to cause infinate
looping around the table (given that DELETED_STRINGs don't count towards the
number of strings considered to be in the table).

Tom came up with a clever fix for the first problem. See:

http://gcc.gnu.org/ml/java-patches/2001-q1/msg00141.html

But I'm not sure that he ever checked it in. I have a plan to fix the second
problem by using buckets and a secondary, free-list table to resolve collisions.
We definatly need to fix this before 3.0, as its a major cause of runtime crashes
for some applications.

regards

  [ bryce ]