Re: INTERN_UTF8CONSTS

Date view Thread view Subject view Author view

From: Archie Cobbs (archie@whistle.com)
Date: Fri Dec 18 1998 - 15:56:06 EST


Godmar Back writes:
> I'm tracking down memory leaks in kaffe ---
> what's the deal with INTERN_UTF8CONSTS?
> I understand that it was an attempt by Per Bothner to implement what?
> interning of all utf8s?
>
> In any event:
>
> + is it working?
> + does anybody still understand how it worked?
> + do we need it?
> + are there any objections to removing it?

My opinion is that we should 'finish the job'..

That is, separate the String objects from the String data, so
the mapping: String objects -> char arrays is a many-to-one mapping.
E.g.:

  public final class String {
    private char[] contents;
    ...
  }

Then a.equals(b) IFF a.contents == b.contents. Or even better,
a.equals(b) IFF a == b (might as well go all the way).

Benefits:

  - You never store the same sequence of chars twice, so it's more
    memory efficient

  - String.equals() is trivial (and fast): it simply checks that
    both strings point to the same internal char array.

  - String.intern() is trivial to implement

I haven't completely thought this out, but this seems like
the way to go to me.

We'd need an internal hash table and some native methods to insure
that when new strings are created, their contents are checked vs.
what char arrays are already in the table, etc.

Doing the hashtable lookup might as well compute the Java hashvalue of
the String, which we can then cache.

Comments? I'd like to attempt this when I get the time..

-Archie

___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:23 EDT