This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
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