patch to String.intern

Per Bothner per@bothner.com
Wed Mar 21 09:28:00 GMT 2001


Tom Tromey <tromey@redhat.com> writes:

> >>>>> "Per" == Per Bothner <per@bothner.com> writes:
> 
> Per> I got a crash in (I think) _Jv_StringFindSlot involving a string
> Per> that had a data field pointing to a separate char[].  I think the
> Per> latter had been zero'd, presumably by some gc bug.  I didn't
> Per> really track down the problem, but it seems to be it makes sense
> Per> that intern'd strings should all be single-object strings
> Per> (i.e. one whose data field is this).
> 
> I agree that this is what we ought to do.
> However I'd also like to understand the underlying bug.
> Do you have a test case?

Yes, Kawa while compiling some semi-big Scheme files.  I intend to
make a Kawa snapshot with the gcj support, so you (or the testsuite)
can just configure it, compile it, and run the Kawa testsuite.  (Which
btw last night ran with gcj no with 0 unexpected errors, when using the
default Kawa calling convention, except that building testing.zip
still fails because of problems in java.util.zip.  Running with full
tail-call support for some reason also fails.)

> I'd prefer not to do this, since to me it seems uglier.  I prefer not
> to use functions that aren't attached to a class.

Why?  If a function is local to a file, why not just keep it local
to the file?  What good is making it a method - it just clutters up
String.java and String.h and the String Class object for no reason at all.

>  Also, pointer-to-member isn't an issue for a static method.

That I think is an C++ implementation issue. Not that matters, as we
don't try to be portable to other C++ compiler.  The real point is
keeping local information local, which both simplifies the visible
interfaces and makes things more efficient.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/



More information about the Java-patches mailing list