uncommon trap for athrow
John.Rose at Sun.COM
Wed Sep 9 19:31:45 PDT 2009
On Sep 9, 2009, at 4:27 PM, Tom Rodriguez wrote:
> We got in a report, 6877221, complaining about the use of the
> uncommon trap below for handling of an athrow. Anyone understand
> why we use an uncommon trap here to dispatch an exception?
That was a long time ago...
That code gets used when a non-call bytecode needs to raise an
exception, and also the method itself has local exception handlers.
So in that case the compiler needs to wire up the potential local
transfers of control between N non-call sites and M handlers. The
wire-up is done by calling rethrow and then processing its result with
catch_call_exceptions, which will eventually set up PC-to-PC mapping
(Confusingly, the rethrow stub jumps to the nmethod's sole exception
handler area, which itself is always just a call to the exception
blob, which after lots of waste movement calls
SharedRuntime::compute_compiled_exc_handler. The PC returned by that
guy is either an unwinder routine, or else a local PC prepared by
I suppose it would work to remove the code the customer is complaining
about, but it might cause catch_call_exceptions to create a large
number of a control flow edges. This in turn could degrade code
quality and/or slow down compile times. Remember that an uncommon
trap is cheaper than a branch, because the state along the trapping
edge goes away, and does not affect downstream optimization or
It's maybe worth an experiment to remove that trap. It would be easy
to put the uncommon trap under a switch.
More information about the hotspot-compiler-dev