Patch: finalize interned strings

[Tom Tromey]

Bryce> Right, but as long as the finalizer is run at some stage
Bryce> *before* the object gets collected, there shouldn't be a
Bryce> problem, so I think what we're trying to do with the finalizer
Bryce> is correct. The pointers in the hashtable are already basically
Bryce> weak references, as the hashtable is allocated as pointer-free
Bryce> memory so it shouldn't be scanned during marking.

Suppose the GC notices that the String "zardoz" is unreachable.
So it schedules it for finalization (we're assuming a GC which does
not immediately finalize).
Then, before the finalizer is run, a new "zardoz".intern() is done.
This resurrects the previously interned String.
At this point the finalizer runs, resulting in "zardoz" being removed
from the intern hash table.

Bryce> I think I may have found the problem though (and now I
Bryce> understand what DELETED_STRING is trying to do): if you have
Bryce> two strings that hash to the same value, _Jv_StringFindSlot
Bryce> will return the wrong index in the case that the first string
Bryce> with the same hash value has already been finalized. Hmm...

Yeah.  We'll have to use 0 as the deleted indicator now, though.
I can't rework my patch until later.

Tom