Hi Etienne,
> From: Etienne M. Gagnon [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 19, 2000 4:04 PM
> Subject: Re: Why catch (NullPointerException e)?
> > > Exceptions should be "exceptional". From a VM
> > > designer point of view, the last thing to
> > > optimize (in priority) is exceptions.
I agree with you that exceptions should be low on the priority of things to
optimize in a VM, but...
While I would also expect that exceptions are "exceptional", that is not the
case for all applications. We have instrumented our VM to count the number
of exceptions thrown during an execution of Java apps and we found that
there exist programs that use exceptions liberally for "non-exceptional"
control flow. Of course those programs are not very common, but they exist.
For instance out of 6 benchmarks in SPEC JVM98
(http://www.spec.org/osg/jvm98), 2 throw a lot of exceptions. Those
benchmarks are javac (over 22,000 exceptions) and jack (over 240,000).
Those numbers are really large, given that those two benchmarks run under 30
seconds on what is today a low end PC. Regardless of personal tastes of VM
writers, it is a tough decision to not optimize for a class of real Java
applications (javac and jack were not written as "benchmarks", they are
actually used in the real world).
> Lastly, I would stress that throwing an exception is a very costly
> matter:
> (1) An exception object needs to be created [gc pressure]
> (2) The constructor of the exception object is called [execution time]
> (3) The stack trace need to be saved [execution time + gc pressure]
> (4) The vm needs to track down an exception handler [execution time]
>
> Some Java interpreters/JITs might be able to optimize this, sometimes,
> by avoiding the whole object creation in some cases (like the empty
> catch clause of your example, in presence of inlining). But, now, you
> are down to optimizing a program for a specific vm, which is not
> necessarily a good idea if you expect your program/library to run on
> various vms. (Anyway, I suspect such vm to translate the exception
> detection into an explicit "if" test, that you tried to avoid in the
> first place;-)
You can avoid that explicit test by using what we call "lazy exceptions".
In our technique as long as the VM can prove that a constructor of an
exception has no side effects (this analysis happens at compile time in our
JIT, so there's no run time overhead), we delay the creation of the
exception object and look for the handler. If the exception object is dead
in the handler, we simply transfer control there without ever going through
steps 1-3 mentioned by you. If OTOH the exception object is live in the
handler, we create it lazily right before transferring control to the
handler. If you're curious, you can find all the details in a paper we
published this year in PLDI. Here's the reference:
Michal Cierniak, Guei-Yuan Lueh and James Stichnoth. "Practicing JUDO: Java
Under Dynamic Optimizations". In Proceedings of the SIGPLAN '00 Conference
on Programming Language Design and Implementation (PLDI), Vancouver B.C.,
Canada, June, 2000
Michal
