review (S) for 6877221: Endless deoptimizations in OSR nmethod
Thomas.Rodriguez at Sun.COM
Tue Feb 16 15:32:12 PST 2010
On Feb 16, 2010, at 3:24 PM, Vladimir Kozlov wrote:
> So making athrow non rerunnable will force to generate runtime call to trow
> instead of uncommon trap. Correct?
Yes and we'll get CatchProj's off the call to handle/describe all the exception edges.
> Otherwise looks fine.
> Tom Rodriguez wrote:
>> 6877221: Endless deoptimizations in OSR nmethod
>> 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
>> 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.
More information about the hotspot-compiler-dev