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.iva...@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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
