VolanoMark findings

Thu Jan 30 03:39:00 GMT 2003

On 2003年1月29日, 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