[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Class loader optimization patch

From: Mark Wielaard
Subject: RE: Class loader optimization patch
Date: 14 Mar 2003 21:03:06 +0100


On Tue, 2003-03-04 at 09:57, Jeroen Frijters wrote:
> Archie Cobbs wrote:
> > Here's another slant on this idea: if you don't care about the
> > stack trace, there's no reason an exception object can't be
> > reused. So the native code could just keep around a pre-allocated
> > exception object and throw it over and over again as necessary.
> > Since it's always caught, it will never "escape" into any code
> > that could try to print out its stack trace.
> Just to point out that not all VMs are the same, on ikvm throwing an
> exception will always cause a stack trace to be built, I cannot avoid
> that, because that is just the way the underlying platform (.NET) works.

But as Archie points out in some cases you really are not interested in
getting the stack trace. For example if you come across the following

catch (Throwable t)
    // Ignore exceptions fall back on default.

At the beginning of the try-catch block you know that any exception
thrown in the block will never get used. So what you can do is set some
Thread local flag that can be checked later when a Throwable is created
that is about to get thrown (but never used for something else). The
flag gets cleared again when you drop out the try-catch block. Then when
you actually have to create and throw an exception and the flag is on
you just skip the whole java exception object creation.

Of course it gets interesting if the code doesn't catch Throwable but
e.g. IOException and if these things get nested but I am sure something
could be worked out for those cases by using a stack that remembers the
most specific exception that will be ignored next and you problably have
to benchmark some programs to see how often this pattern occurs and and
which situations doing all the bookkeeping is just overhead. There must
be papers about such exception elimination techniques.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]