This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: string hash performance
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Eric Blake <ebb9 at email dot byu dot edu>
- Cc: java at gcc dot gnu dot org
- Date: Wed, 7 Aug 2002 21:32:02 -0400 (EDT)
- Subject: Re: string hash performance
On Wed, 7 Aug 2002, Eric Blake wrote:
> Classpath's implementation also caches the hashcode. You can also
> verify, by reflection, that Sun's version of the JDK likewise does
> caching.
Interesting. I also noticed in hprof output that Object instances are 4
bytes while Strings are 20 bytes.
> Thus, if gcj does merge with
> classpath, all String objects would become at least 4 bytes larger to
> store the cache.
It's hard to say if String is better off with or without. At least
cachedHashCode need not be volatile or synchronized since any
loads/stores should be atomic.
My interpreter needs some large string tables. I'll see about
benchmarking it with cachedHashCode.
Jeff