review (S) for 6877221: Endless deoptimizations in OSR nmethod

[Tom Rodriguez]

http://cr.openjdk.java.net/~never/6877221

6877221: Endless deoptimizations in OSR nmethod
Reviewed-by:

When emitting the inline exception code if we can't handle all the
exception types inline we will try to fall back to an uncommon trap
for bytecodes that can be rerun to produce the exceptional condition.
All bytecodes except the various invokes can be handled this way.  The
cases we currently can't handle inline are unloaded catch classes,
which will require class loading during lookup and catch classes that
have subclasses.  That latter is a historical limitation from the
times when type checks were more expensive.  Currently athrow is
handled by rerunning it which means that any exception forwarding
logic that uses athrow will force us back into the interpreter for
every exception dispatch through this nmethod.  Since this fix will
likely be backported I want to do the simple fix of removing athrow
from the set of rerunnable bytecodes.  A more complete fix involving
rewriting catch_inline_exceptions to avoid the uncommon trap with
Action_none and to perform full type checks inline will be done for
hs18.

I collected some stats on how catch_inline_exceptions behaves to get
some sense of which paths are used.  These numbers are generated every
benchmark in reference_server plus specjvm2008.  In 22631 calls, 16050
terminate by unwinding the frame, 3280 dispatch to a default exception
handler, 3176 call the rethrow function, and 125 emit an uncommon
trap.  Of those uncommon traps the bytecode breakdown is this:
  
  14 anewarray
  52 athrow
  52 new
   7 newarray

Of the athrows, 43 are from unloaded classes and the other 9 are
because the catch class had subclasses.

src/share/vm/opto/parse1.cpp