Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8063302 | 8u45 | Vladimir Ivanov | P4 | Resolved | Fixed | b01 |
JDK-8058358 | 8u40 | Vladimir Ivanov | P4 | Resolved | Fixed | b06 |
JDK-8071038 | emb-8u47 | Vladimir Ivanov | P4 | Resolved | Fixed | team |
There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar "linker methods") and the PopFrame feature. The linker methods accept an extra "appendix argument" of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method).
In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle.
This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point.
Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized.
In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle.
This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point.
Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized.
- backported by
-
JDK-8058358 JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
-
- Resolved
-
-
JDK-8063302 JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
-
- Resolved
-
-
JDK-8071038 JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
-
- Resolved
-
- relates to
-
JDK-7187554 JSR 292: JVMTI PopFrame needs to handle appendix arguments
-
- Resolved
-