United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6917766 JSR 292 needs its own deopt handler
6917766 : JSR 292 needs its own deopt handler

Details
Type:
Enhancement
Submit Date:
2010-01-18
Status:
Closed
Updated Date:
2011-03-14
Project Name:
JDK
Resolved Date:
2011-03-14
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P4
Resolution:
Won't Fix
Affected Versions:
hs17
Fixed Versions:
hs17

Related Reports
Relates:
JDK-6921352 - JSR 292 needs its own deopt handler (new CR for 6917766)
Relates:
JDK-6921339 - backout 6917766

Sub Tasks

Description
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.

Comments
EVALUATION

The fix was wrong, was pushed accidentially and got backed out (see 6921339).
2010-01-29


Hardware and Software, Engineered to Work Together