> Obviously the problem is not the exception throwing or handling, the problem
> is the exception class object instantiation. But Object instantiation in
> general is not the problem

More specifically, the problem is in findMethodFromPC(), which is
called to fill in a backtrace, which is called by the Throwable
constructor.  One only has to look at this function (down at the
bottom of classMethod.c) to see that it is god-awful slow.  Especially
when you consider that a large number of the PCs passed into this
method are for native code (e.g., code that has no associated method.)

I've done some (gprof) profiling of kaffe running java code that
doesn't throw any explicit exceptions and still this function is near
the top of the gprof heap.

I made one rather simple optimization to my local tree (which is soo
far out of whack that you don't want to see the diff) but I think a
re-thinking of how this functionality is performed in Kaffe is needed.
Here's the optimization anyway:  Have the JIT'r record the max and min
addresses for code generated so far (in jit/machine.c down in
installMethodCode().)   Then provide an interface for
findMethodFromPC() to ask the JIT'r for these values so it can perform
a first-pass elimination of pc's (this has the distinct advantage that
it eliminates those pc's that have no java method assocaiated with
them.)

Any one have better ideas?

-Pat