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
