RE: VolanoMark findings

[Jeff Sturm <jsturm at one-point dot com>]

On Wed, 29 Jan 2003, Boehm, Hans wrote:
> 5. _Jv_CheckCast

Empirically this and _Jv_IsInstanceOf are far slower than their
counterparts in the JDK.  I once tried a patch to inline the
fast path of both functions.

Part of the difficulty with _Jv_IsInstanceOf is that it can be hard to
predict the outcome statically.  I measured a relatively high count of
branch misses in this function.  Inlining this code, plus feedback
optimizations (-fprofile-arcs/-fbranch-probabilities) improved my
interpreter benchmark considerably, something on the order of %10 wall
clock time.

> out of line division (> 5% total, in various routines)

Functions like _Jv_divI aren't declared "pure".  Should they be?

The GCC docs don't say whether pure functions are allowed to throw
exceptions.

> memory allocation (not GC)

The frontend should probably invoke GC_gcj_malloc directly.  I noticed
this comment in misc.c:

#	ifdef GC_GCJ_SUPPORT
	   /* Make all sizes up to 32 words predictable, so that a 	*/
	   /* compiler can statically perform the same computation,	*/
	   /* or at least a computation that results in similar size	*/
	   /* classes.							*/
	   for (i = 16*sizeof(word) + 1; i <= 32 * sizeof(word); i++) {
	      GC_size_map[i] = (ROUNDED_UP_WORDS(i) + 3) & (~3);
	   }
#	endif

So this could avoid the GC_size_map lookup on the allocation path, but
isn't actually implemented anywhere?

Jeff