uncommon trap for athrow

[Tom Rodriguez]

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

That makes some sense.  I hadn't considered the extra edges that would  
be produced.  It does mean that the exception path is much slower than  
it needs to be.  In the test case it's explicitly throwing an  
exception which is going to be caught elsewhere in the method.  It's  
clearly been boiled down from something larger which is why it looks  
so silly.

while (true) {
   try {
     try {
       work();
       throw new Exception();
     } finally {
     }
   } catch (Exception e) {
   }
}

The throw causes an uncommon trap and then we spend time in the  
interpeter until we re-osr.  The finally block acts as a funnel for  
all possible exceptions which keeps us from optimizing the throw into  
a direct transfer of control in the original compile.

Disabling can_rerun_bytecode seems risky.  For this case disallowing  
athrow from rerunning would probably fix it without expanding the  
number of edges too much though it seems like kind of a hack.   
Alternatively maybe the uncommon trap needs to have a proper trap  
count like other kinds of uncommon traps so that we could avoid it if  
it's hot.  That might be better.

Thanks!

tom

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