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.
Also, I made DirectMethodHandles a special-case, since I don't see any
benefit in customizing them.
Best regards,
Vladimir Ivanov
On 1/21/15 10:30 PM, John Rose wrote:
On Jan 21, 2015, at 9:31 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
in Invokers.java, I think that checkCustomized should take an Object and not a
MethodHandle
exactly like getCallSiteTarget takes an Object and not a CallSite.
The use of erased types (any ref => Object) in the MH runtime is an artifact of
bootstrapping difficulties, early in the project. I hope it is not necessary any
more. That said, I agree that the pattern should be consistent.
Vladimir, would you please file a tracking bug for this cleanup, to change MH
library functions to use stronger types instead of Object?
in MethodHandle.java, customizationCount is declared as a byte and there is no
check that
the CUSTOMIZE_THRESHOLD is not greater than 127.
Yes. Also, the maybeCustomize method has a race condition that could cause the counter
to wrap. It shouldn't use "+=1" to increment; it should load the old counter
value, test it, increment it (in a local), and then store the updated value. That is
also one possible place to deal with jumbo CUSTOMIZE_THRESHOLD values.
— John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
