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.
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.
- relates to
-
JDK-6921339 backout 6917766
-
- Resolved
-
-
JDK-6921352 JSR 292 needs its own deopt handler (new CR for 6917766)
-
- Resolved
-