RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact
vladimir.x.ivanov at oracle.com
Fri Jan 23 16:00:53 UTC 2015
Good idea, Peter!
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:
>>> 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
> 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...
>> (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
More information about the core-libs-dev