Looks good.
While touching the code some time ago John and I were playing around with the
idea to call Class.cast in the failing case:
+ static <T,U> T castReference(Class<? extends T> t, U x) {
+ // inlined Class.cast because we can't ForceInline it
+ if (x != null && !t.isInstance(x))
+ t.cast(x);
+ return (T) x;
+ }
+
Then we don’t have to duplicate the throwing logic.
On Feb 25, 2014, at 4:16 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com>
wrote:
> http://cr.openjdk.java.net/~vlivanov/8033666/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8033666
>
> ValueConversions::castReference was introduced to workaround a problem
> with unreliable inlining of Class::cast method. Unfortunately, since
> ValueConversions class is located in sun.invoke.util,
> @java.lang.invoke.ForceInline annotation isn't visible to it.
>
> A proper fix would be to teach Hotspot to treat Class::cast specifically
> and always inline it, but it requires extensive exploration of
> performance implications. Filed 8035809 [1] to track that.
>
> As an interim fix, I moved castReference method into
> java.lang.invoke.MethodHandleImpl class and added new entry point
> ValueConversions::cast which accepts a method handle to a method which
> should be used for casting.
>
> Testing: manual (looked through -XX:+PrintInlining output to ensure
> MHI::castReference is inlined), jdk/java/lang/invoke, octane.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] 8035809: Improve inlining of Class::cast method
> https://bugs.openjdk.java.net/browse/JDK-8035809
>
> _______________________________________________
> 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
