Re: Patch: finalize interned strings

[Tom Tromey <tromey at cygnus dot com>]

Bryce> I actually did exactly this in my own tree last night, but
Bryce> didn't post the patch because it is still buggy.

Sorry.  Too eager again.

Bryce> _Jv_StringFindSlot() can get stuck in an infinate loop looking
Bryce> for a slot when it encounters DELETED_STRINGs. I got rid of the
Bryce> DELETED_STRING stuff (which I don't really understand), and
Bryce> then found that I was still getting crashes that appeared to be
Bryce> collected Strings still present in the hashtable.

Bryce> I'm now wondering: Does the collector guarentee that finalizers
Bryce> will be run immediatly when an object is collected? Or can the
Bryce> running of finializers be deferred until a later collection in
Bryce> some cases?

I forgot about this too.  Sigh.  I probably need a vacation.

I don't think we should assume when finalizers might be run.
Eventually we'll want different GCs, not all of which will work the
exact same way.

At first when I read your (quoted) message I thought this was a problem.
Then I thought it wasn't a problem, because this is just a funny way
resurrecting the String from the finalizer (which is perfectly ok).
But now I think again that it is a problem, because it is possible
to resurrect the item before the finalizer is actually run.
I don't think we have any way to detect that.

I agree that the DELETED_STRING stuff doesn't seem to make sense.

I've backed out my change.

I'll send a new change that introduces weak refs soon.  Could you test
it?

Tom