uncommon trap for athrow

[John Rose]

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  
tables.

(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  
catch_call_exceptions.)

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  
register allocation.

It's maybe worth an experiment to remove that trap.  It would be easy  
to put the uncommon trap under a switch.

-- John