RE: Class loader optimization patch

[Jeroen Frijters]

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