-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b07
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2187241 | 7 | John Rose | P3 | Closed | Fixed | b80 |
JDK-2189985 | 6u21 | John Rose | P3 | Resolved | Fixed | b01 |
The JITs (C1, C2) must not bail out to the interpreter when they encounter an invokedynamic call site. Rather, they must load the target method from the CallSite and perform a MethodHandle.invoke call on it, and possibly also call the bootstrap method. The target method, if available at compile time, should be optimistically inlined, as if for a bimorphic call site. Bail-outs to the interpreter should be limited to deoptimizations, as with other dynamically typed call sites.
The structure of the target method handle should be reified to the compiler as a "synthetic method", a ciMethod or even a real methodOop. In this way the usual bytecode parser can be used to generate the IR for it. This design will also allow method handles to be shrink-wrapped when necessary, as (for example) in interface injection.
The structure of the target method handle should be reified to the compiler as a "synthetic method", a ciMethod or even a real methodOop. In this way the usual bytecode parser can be used to generate the IR for it. This design will also allow method handles to be shrink-wrapped when necessary, as (for example) in interface injection.
- backported by
-
JDK-2189985 compiler optimizations required for JSR 292
-
- Resolved
-
-
JDK-2187241 compiler optimizations required for JSR 292
-
- Closed
-
- relates to
-
JDK-6925249 assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos")
-
- Resolved
-
-
JDK-6655638 dynamic languages need method handles
-
- Closed
-
-
JDK-6655646 dynamic languages need dynamically linked call sites
-
- Closed
-