RFR (S): 8033666: Make sure @ForceInline is everywhere it needs to be in sun.misc and java.lang.invoke

[Christian Thalinger]

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.ivanov at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev