[arch] throwing lazy exceptions

[Steve Shih-wei Liao <li...@gmail.com>]

Throwing an exception can be expensive. We found that a big chunk of
execution time of 213.javac is spent on exception object creation and
filling the stack trace for the object. However, almost 90% of catch
blocks are empty. The concept of lazy exception is to construct an
exception object only when the object is indeed referenced in the
catch block or when the object's constructor has side effects and
hence must be executed. Note that ORP team implemented lazy exceptions
a few years ago. A paper, "Practicing JUDO: Java under dynamic
optimizations" was published at PLDI'2000. We are now revisiting the
optimization of exception throwing.

Below is our JIT algorithm to optimize code using lazy exceptions. 

  if (exceptionObjectConstructorHasSideEffects) {
    generate code for new
    generate code for dup 
    generate code for invokespecial
    generate code for athrow
  } else {  
    generate code for managed code to enter VM code (through invoking
"VM_RT_THROW_LAZY" helper) and pass exception object constructor's
arguments to VM
  }

First, JIT analyzes whether a particular method has "side effect" and
sets the flag during compilation, though VM may mark some methods of
the system classes itself. The JIT algorithm above will query the flag
first.

Second, if the flag is not set, in the helper "VM_RT_THROW_LAZY" VM
searches for the exception handler by iterating over the stack. When
VM finds the handler, it checks if the handler has been registered by
JIT and if the boolean "exception_object_is_dead" is set to true by
the JIT. If yes, VM simply transfers the control to the handler
without creating the exception object, invoking its constructor and
filling its stack trace. That is, the exception is lazy.

Does anyone on the mailing list like to comment on the design above
and share the performance data on exception handling/optimizations?
I'm also interested in finding out if there are other benchmarks/apps
that would benefit from this optimization. Or perhaps additional
schemes we should be investigating? Does other open source JVM
implement similar schemes? Thanks,
    Steve Liao, Intel