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

[Igor Veresov]

Looks good!

igor

> On Aug 17, 2016, at 6:08 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 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