RE: Class loader optimization patch

[Mark Wielaard]

Hi,

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
code:

try
  {
    doSomething();
  }
catch (Throwable t)
  {
    // Ignore exceptions fall back on default.
    doSomethingElse();
  }

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.

Cheers,

Mark