string hash performance

[Jeff Sturm]

On Wed, 7 Aug 2002, Eric Blake wrote:
> 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.

I did some benchmarking with the cachedHashCode bits of your patch.
Interestingly, it helped considerably on my interpreter benchmarks,
chopping about 15% off total run time.

I also tried some other common techniques.  All runs with -O2
-fno-bounds-check -fno-store-check, additional switches as indicated:

i686-pc-linux-gnu

millis
------
  1070
   863  static
   731  static + hashcode
   612  static + hashcode + ms8m
   653  static + hashcode + ms8m + inline[1]
   603  static + hashcode + ms8m + inline[2]

static    = linked with libgcj.a
hashcode  = libgcj rebuilt with Eric's cachedHashCode patch
ms8m      = initial heap set to 8MB (via GC_INITIAL_HEAP_SIZE)
inline[1] = app built with Andrew's inliner patch and -finline-functions
inline[2] = additional tweaks over inline[1], e.g. max-inline-insns=100

In comparison:

millis
------
   673  HotSpot 1.4 -client
   540  HotSpot 1.4 -server
   549  IBM JDK 1.3.0
   110  tclsh 8.3

(the last is from the C-based interpreter, of course.  Whoever said Java
could be faster than C?)

There is still quit a bit of improvement possible here though I'm not sure
where it will come from.  I had trouble getting any real improvement from
the inliner, but it is still experimental code.

Jeff