This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Exception Handling


On Saturday 12 June 2004 20:58, Andrew Haley wrote:
> Chris Gray writes:
>  > On Saturday 12 June 2004 17:47, Andrew Haley wrote:
>  > > Jeroen Frijters writes:
>  > >  > Chris Gray wrote:
>  > >  > > I don't have any hard numbers either, but my experience leads
>  > >  > > me to believe that exceptions are thrown far more often than most
>  > >  > > VM/compiler developers would like to think.
>  > >  >
>  > >  > I agree.
>  > >
>  > > It's possible, but AFAICS the really interesting number is the ratio
>  > > of try/throw.
>  > >
>  > >From the gcj point of view, yes.
>
> From any point of view, surely.  If we're trying to minimize runtime
> in the usual case, that's what we need to know.  Speeding up code in
> the case when the whole system fails seems, well, less interesting...
>
> :-)

We were discussing a design decision in gcj, which was to have no overhead for 
"try" and rather a high overhead for "throw"; in this case the try/throw 
ratio is indeed the most interesting. For other runtimes, "try" might not 
even be a data point; they might be more interested in e.g. the ratio of 
normal method returns to abnormal ones.

There's a big difference between "an exception is thrown" and "the whole 
syatem fails". Consider the case of a user-defined class loader: every time 
it successfully loads a class from its own resources, it first has to 
delegate to its parent and catch a ClassNotFoundException. If the parent has 
a parent then there will be mutliple exceptions thrown for each class that is 
loaded.

>  > The number of stack frames which have to be unwound is probably
>  > also of interest: my guess would be that many throws are caught in
>  > the same stack frame, but a substantial number will propagate a
>  > long way up the stack.
>  >
>  > I think the measurements will have to be done by instrumenting the
>  > compiler - it's not easy for a runtime such as IKVM (or Wonka) to
>  > know that a try{} block is being entered. IOW I'm not volunteering
>  > to make the measurements, just suggesting that Somebody should do
>  > something. :)
>
> Well, I can do it easily, but then I have to have a corpus of code to
> measure.  And some reason to do the study at all: unless there is a
> realistic prospect of defining a new unwinder mechanism, there will be
> little point.

Yes of course there has to be an a priori case to answer, and some likelihood 
that if the try/throw ratio proves to be low then some effort to define a new 
unwinding mechanism will be made. That's optimisation for you: guess, 
measure, experiment, repeat.

Cheers

Chris

> Andrew.

-- 
Chris Gray                      /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
chris.gray@kiffer.be                         +32 3 216 0369


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]