[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Class loader optimization patch
From: |
Jeroen Frijters |
Subject: |
RE: Class loader optimization patch |
Date: |
Sat, 15 Mar 2003 13:47:00 +0100 |
Hi,
What I was trying to make clear was that I have no control over (some
aspects of) this. I have to use the .NET exception handling facilities
and I'm stuck with its (in)efficiency.
Regards,
Jeroen
>
> -----Original Message-----
> From: Mark Wielaard [mailto:address@hidden
> Sent: Friday, March 14, 2003 21:03
> To: Jeroen Frijters
> Cc: Archie Cobbs; address@hidden; Prof. Etienne M. Gagnon
>
> 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
>
>
- Re: Classpath AWT problems (or gtk problems...), (continued)