Re: string hash performance

[Eric Blake <ebb9 at email dot byu dot edu>]

Classpath's implementation also caches the hashcode.  You can also
verify, by reflection, that Sun's version of the JDK likewise does
caching.  My patch for merging String between Classpath and gcj would
let gcj also do caching, but Tom Tromey still has not had time to review
it (it may need several updates by now, as I have not looked at it in a
while, and several other patches have since been applied to Classpath's
version of String).
<http://gcc.gnu.org/ml/java-patches/2002-q1/msg00778.html>

Jeff Sturm wrote:
> 
> 
> I'd wondered if the JIT wasn't fooling my benchmark again, somehow
> inlining hashCode() and hoisting the result.  Further tests suggest that
> isn't the case.  Could it be the JDK stores hash codes somewhere in a
> java.lang.String?  I would've thought the implementation would favor size
> over speed.
> 

In response to Hans answer, String.hashCode does not use
Object.hashCode, so the location of a String object in memory has no
effect on whether hashing would be useful.  Thus, if gcj does merge with
classpath, all String objects would become at least 4 bytes larger to
store the cache.  Tom, that may be something for you to consider when
you ever do get around to looking at my patch.

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer