RFR: 8164214: [JVMCI] include VarHandle in signature polymorphic method test

Doug Simon doug.simon at oracle.com
Wed Aug 17 13:08:29 UTC 2016


Please review this change that should have been part of 8163962. The problem is that java.lang.invoke.VarHandle needs to be treated the same as java.lang.invoke.MethodHandle when resolving invoke bytecodes, especially when the resolution should be eager (e.g., as may be required for ahead of time compilation).

I removed ResolvedJavaMethod.isSignaturePolymorphic(...) as well since a) it was broken and b) we should rely as much as possible on VM code to do the test for whether a method is signature polymorphic to be more future proof.

Note that in HotSpotConstantPool.java I also converted sanity check methods of the form `void assert<Condition>(...)` to `boolean check<Condition>(...)` so that the call itself is only made when assertions are enabled. Some of these checks make VM calls which can slow down constant pool resolution and thus bytecode parsing. I can refactor this change into a separate bug if anyone insists.

https://bugs.openjdk.java.net/browse/JDK-8164214
http://cr.openjdk.java.net/~dnsimon/8164214

-Doug


More information about the hotspot-compiler-dev mailing list