Re: Patch: finalize interned strings

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

Tom Tromey wrote:

> 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.

Oh, I see. Looks like we do need proper weak reference support (calling
GC_register_disappearing_link() should do the trick?). We probibly want
to do this in order to implement JDK1.2 weak reference support, too.

> 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.

I think the solution is to have unintern() not call _Jv_StringFindSlot(),
but rather traverse the hashtable until it finds itself. But I thought of
another possible problem - what happens if we call
_Jv_RegisterFinalizer() for a string more than once (which would happen
if intern() is called on the same object more than once). Does the gc
guarantee that a finializer will only be called once, even if it is
registered twice?

regards

  [ bryce ]