The speed of exception handling !?!

[Tim Wilkinson]

I suppose I always considered exceptions to be, well the exception - so
the speed didn't really matter.  But now someone's demonstrated how
awful it actually is I thought I'd take a look.

Seems to me that the thing to do is not so much fixup findMethodFromPC
(though this would undoubtable help) but to avoid calling it in the
first place.  At the moment an exception constructs an array of
character strings to hold the backtrace (rather like how Sun's JVM does
it I believe).  This is basically stupid - instead you should build an
array of Method/PC pairs (or for the JIT just PC's) and only construct
the textual backtrace on demand.

I've now implemented this and will upload it to CVS in the next few
days.  I haven't done any timings yet but it should essentially
eliminate the need to call findMethodFromPC except when you actually
want to print the backtrace info.  Any thrown and caught exceptions will
never need to call it.

Cheers
Tim

tullmann at cs.utah.edu wrote:
> 
> > 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

--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,	Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim at transvirtual.com