[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
From:       Vladimir Ivanov <vladimir.x.ivanov () oracle ! com>
Date:       2014-05-29 9:32:55
Message-ID: 5386FEC7.7080501 () oracle ! com
[Download RAW message or body]

John, Serguei, thanks for review.

Best regards,
Vladimir Ivanov

On 5/28/14 9:37 AM, serguei.spitsyn@oracle.com wrote:
> Vladimir,
>
> It looks good.
>
> Thanks,
> Serguei
>
> On 5/26/14 12:25 PM, Vladimir Ivanov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8034935
>> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
>>
>> 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
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>
[prev in list] [next in list] [prev in thread] [next in thread]