Re: Speeding up method searches

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Per Bothner wrote:

> Not necessarily - it can be handled in one of the class load/init phases.
>
> What about if in inappropriate data structures we replaced Utf8Const by
> statically allocated String objects.? The init code can then intern the
> strings.

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. How will this be implemented?

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.

I think interning would be the right way to go, especially if we can
efficiently store pre-computed hashcodes for the pre-allocated strings (is
storing hashcodes for runtime strings worth the extra space?). In any case, the
extra interning overhead at class initialization should be more than offset by
the efficiencies gained in the interface table generation.

> Where the linker support would help is that we could in the best case
> do the interning at link time (even create the hash table at link time!).
> If not that, we could have the linker remove duplicate String objects
> to the best of its ability.

In the case of dynamic linking , it probibly won't make much difference exactly
where the interning is done - so I guess linker support for interning is
something which we can worry about later.

regards

  [ bryce ]