[9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

[Vladimir Ivanov]

Good idea, Peter!

Updated version:
http://cr.openjdk.java.net/~vlivanov/8069591/webrev.02/

Best regards,
Vladimir Ivanov

On 1/23/15 5:38 PM, Peter Levart wrote:
> On 01/23/2015 12:30 AM, John Rose wrote:
>> On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov
>> <vladimir.x.ivanov at oracle.com> wrote:
>>> Remi, John, thanks for review!
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~vlivanov/8069591/webrev.01/
>>>
>>> This time I did additional testing (COMPILE_THRESHOLD > 0) and
>>> spotted a problem with MethodHandle.copyWith(): a MethodHandle can
>>> inherit customized LambdaForm this way. I could have added
>>> LambdaForm::uncustomize() call in evey Species_*::copyWith() method,
>>> but I decided to add it into MethodHandle constructor. Let me know if
>>> you think it's too intrusive.
>> It's OK to put it there.
>>
>> Now I'm worried that the new customization logic will defeat code
>> sharing for invoked MHs, since uncustomize creates a new LF that is a
>> duplicate of the original LF.  That breaks the genetic link for
>> children of the invoked MH, doesn't it?  (I like the compileToBytecode
>> call, if it is done on the original.)  In fact, that is also a
>> potential problem for the first version of your patch, also.
>>
>> Suggestion:  Have every customized LF contain a direct link to its
>> uncustomized original.  Have uncustomize just return that same
>> original, every time.  Then, when using LF editor operations to derive
>> new LFs, always have them extract the original before making a
>> derivation.
>
> The customized LF then don't need 'transformCache' field. It could be
> re-used to point to original uncustomized LF. That would also be a
> signal for LF editor (the 4th type of payload attached to transformCache
> field) to follow the link to get to the uncustomized LF...
>
> Peter
>
>>
>> (Alternatively, have the LF editor caches be shared between original
>> LFs and all their customized versions.  But that doesn't save all the
>> genetic links.)
>>
>>> Also, I made DirectMethodHandles a special-case, since I don't see
>>> any benefit in customizing them.
>> The overriding method in DHM should be marked @Override, so that we
>> know all the bits fit together.
>>
>> — John
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>