[kaffe] Re: Destroyed strings...

[Patrick Tullmann]

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

I don't think this would work because the char[] could be gone before
the String object is moved to the finalizer list...  The only thing
keeping the char[] alive is the live String reference.  If the only
reference to the String is in the table, then the char[] will get
collected.

> Also, I suppose you could just gc_add_ref() the array on intern and
> gc_rm_ref() on unintern.

I don't think the unintern would ever get called because the String
would always have a reference.  This would solve the problem, but fill
the string table with unused intern'd strings.  :)


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

I think there was some effort to split these two locks in the
past... there must have been a good reason for that....  I don't know
if the increased contention for the lock would make any difference (or
the potential recursive acquires)....


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

I think we'd just have to treat the weaker reference objects like
intern'd Strings are now.  When the destroy method is invoked on such
an object, some special code would have to be invoked (depending on
the type of weaker reference).  

Hmm... the problem is that any objects referred to by that "weak"
object must be considered reachable, so we'll have to treat them more
like finalizables than like intern'd Strings....

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
	    Research is not just an adventure, its a job.