-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b20
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2228531 | 8 | John Rose | P3 | Resolved | Fixed | b52 |
JDK-8017939 | 7u45 | Christian Thalinger | P3 | Closed | Fixed | b01 |
JDK-8002741 | 7u40 | Christian Thalinger | P3 | Closed | Fixed | b01 |
Internally to the JVM, method handle argument list transformations are implemented on the interpreter stack. This means that when compiled code invokes a method handle with argument transforms, it goes through a C2I adapter, transforms the argument list in interpreted format, and then (presumably) goes through an I2C adapter.
At least the most important transforms should go through customized code. These include:
- direct access (no transforms)
- receiver binding (the bindTo transformation)
- trivial asType transformations
- invokeGeneric (argument and return value conversions to and from Object)
Probably all of the core transforms on MethodHandle virtual methods (not necessarily MethodHandles static methods) should get favorable treatment for compiled-to-compiled calls.
An important customer is Project Lambda, which should be using method handles in preference to anonymous classes. Getting the above paths right for compiled code will enable this choice.
Note that this bug does not apply to users invokedynamic, since method handles at invokedynamic call sites are routinely inlined into optimized code.
- backported by
-
JDK-2228531 JSR 292 method handle invocation needs a fast path for compiled code
-
- Resolved
-
-
JDK-8002741 JSR 292 method handle invocation needs a fast path for compiled code
-
- Closed
-
-
JDK-8002742 JSR 292 method handle invocation needs a fast path for compiled code
-
- Closed
-
-
JDK-8002743 JSR 292 method handle invocation needs a fast path for compiled code
-
- Closed
-
-
JDK-8017939 JSR 292 method handle invocation needs a fast path for compiled code
-
- Closed
-
- relates to
-
JDK-7187290 nightly failures after JSR 292 lazy method handle update
-
- Closed
-
-
JDK-6829188 missing method handle adapters required for JSR 292
-
- Closed
-
-
JDK-8011952 Missing ResourceMarks in TraceMethodHandles
-
- Closed
-
-
JDK-7187454 stack overflow in C2 compiler thread on Solaris x86
-
- Closed
-
-
JDK-8033671 Groovy fails to pass tests with invokedynamic (latest sources for JDK7)
-
- Resolved
-
-
JDK-7093795 JSR 292: Seph bench/bench_arithmetic.sp fails with: NoClassDefFoundError: seph/lang/SephObject
-
- Resolved
-
-
JDK-7093796 JSR 292: Rtalk test case fails with: NoClassDefFoundError: ri/core/rtalk/RtObject
-
- Resolved
-
-
JDK-7111583 JSR 292: JRuby test_respond_to.rb fails with: NoClassDefFoundError: org/jruby/runtime/ThreadContext
-
- Resolved
-
-
JDK-8000999 backport of JSR 292 to 7u
-
- Closed
-
-
JDK-8168926 C2: Bytecode escape analyzer crashes due to stack overflow
-
- Closed
-
-
JDK-7088481 JSR 292: remove the vm specific fields from the java.lang.invoke classes
-
- Closed
-