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. (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
