> Godmar wrote: > > You're right. We can't have strings pending to be destroyed in the > > intern table when there's a chance others might try to intern > > identical strings. So we must synchronize against the intern lock > > somehow, ideally without deadlocking. > > Perhaps the intern'd string table should be walked, but only the > char[] objects referenced from it should be marked (not the Strings).
You could mark objects meant to be destroy()ed like objects meant to be finalized... Also, I suppose you could just gc_add_ref() the array on intern and gc_rm_ref() on unintern. > (I think the intern table is currently ignored by the GC.) it is > This would prevent the race conditions because the char[] could never > disappear before the contianing String object did. > > I'm not sure if there's an implicit deadlock in having the GC acquire > the string table lock... Can we just drop the string table lock and use the gc_lock instead? They seem to be mingling quite a bit. Would this also "solve" the nastiness with the stringAlloc()/stringFree() functions having to unlock the stringLock. Also, how does this stuff relate to the soft/weak/phantom reference stuff? I'm not saying we implement it now, but it seems like they would share a some of the same problems/solutions. Just wondering aloud... > -Pat tim _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe