RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
vladimir.x.ivanov at oracle.com
Thu May 29 09:32:55 UTC 2014
John, Serguei, thanks for review.
On 5/28/14 9:37 AM, serguei.spitsyn at oracle.com wrote:
> It looks good.
> On 5/26/14 12:25 PM, Vladimir Ivanov wrote:
>> Citing John's explanation of motivation for this change (from the bug):
>> "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."
>> Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist
>> Best regards,
>> Vladimir Ivanov
More information about the hotspot-compiler-dev