This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Speeding up method searches


Per Bothner wrote:

> > Ok, so the behavior of the constructors for String would need to be
> > special-cased somehow, because they need to return a reference to an already
> > existing String (rather than allocate a new one) in the case where a match
> > already exists in the intern hashtable.
>
> Actually, no.  String *constructors* do not need to do interning.
> Just the intern function.  And intern never needs to construct
> a new String - it either returns the argument, or a String
> previously interned.

Right, that makes sense. Something had me confused there!

> > How do interned strings get garbage collected? The intern hashtable would need
> > to use some kind of weak referencing scheme (so that the collector won't
> > consider the pointers in the hashtable to be legitimate references), and
> > runtime-allocated Strings would need to have a finalizer to remove themselves
> > from the hashtable when they get collected.
>
> Basically - though only for those Strings that *are* interned.

Right. Actually, it seems to me that the collector already doesn't consider the
pointers in the intern table for marking, since it is allocated with _Jv_AllocBytes
which is for "pointer-free" memory. However, there is nothing to remove a collected
string from the hashtable, so we currently get "random" crashes when calling
intern()[*].

regards

  [ bryce ]

[*] - I noticed this bug a while back when running Kaffe's testsuite against libgcj.
I tried to debug it at the time and couldnt figure out what was going wrong. Now its
all very clear ;-)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]