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

[Peter Levart]

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