[kaffe] Re: Destroyed strings...
gback at cs.utah.edu
Wed Jun 5 13:39:24 PDT 2002
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.
> > Godmar wrote:
> > > The string with the dead char array should at this point already be
> > > scheduled for destruction. So one possible way would be to take the
> > > gc_lock and block on intern() if the mustfree is not empty.
> > That seems like it might work...
> > > A quick hack would be to destroy all strings first then the rest,
> > > this way a string would always be destroyed before its char
> > > object.
> > Hmmm... actually, we could pretty easily have two mustfree lists. One
> > for objects with "destroy" methods, and one for all the other objects.
> > That would accomplish the ordering without too much magic required in
> > finishGC.
> > Its not pretty, though.
> Don't we still having the same problem with a second thread though:
> thread action
> U1 s = io.readLine(); // reads "FooBar"
> GC STOPWORLD();
> GC puts interned "FooBar" on mustfree list.
> GC RESUMEWORLD();
> U1 s.intern();
> GC stringDestory("FooBar");
> Now U1 has a pointer to something thats been freed... right? Maybe i'm
> missing something.
> > Given that we know what's happening, I've been surprised by the fact
> > that I can't come up with a test case that causes this problem on
> > existing Kaffe, or other engines. I'd have more faith in a fix for
> > this problem if there was a test case that caused the problem on more
> > installations of Kaffe than just the
> > interp-debug-with-per-JNI-method-exceptions-patch....
> > Let me know if you can come up with a test case that tickles this
> > problem....
> seems impossible to make something reliable here...
> > -Pat
> kaffe mailing list
> kaffe at kaffe.org
More information about the kaffe