patch to String.intern

Per Bothner
Wed Mar 21 09:28:00 GMT 2001

Tom Tromey <> writes:

> >>>>> "Per" == Per Bothner <> 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
still fails because of problems in  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 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

More information about the Java-patches mailing list