JDK-6917766 : JSR 292 needs its own deopt handler
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs17
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2010-01-18
  • Updated: 2011-03-14
  • Resolved: 2011-03-14
Related Reports
Relates :  
Relates :  
When a deoptimization happens at a MethodHandle call site, we need to restore the preserved SP when we walk the stack.  During the stack walk we don't know yet if the original pc is a MH call site until we built the caller frame, but we only can build the caller frame when we load the correct SP, which depends on whether the call site is a MH call site or not.

To handle this chicken-egg problem we need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not.

EVALUATION The fix was wrong, was pushed accidentially and got backed out (see 6921339).