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

Vladimir Kozlov Vladimir.Kozlov at Sun.COM
Tue Feb 16 15:24:20 PST 2010


So making athrow non rerunnable will force to generate runtime call to trow
instead of uncommon trap. Correct?

Otherwise looks fine.


Tom Rodriguez wrote:
> 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

More information about the hotspot-compiler-dev mailing list