[Nestmates] RFR (S): 8197915: [Nestmates] Implement receiver typecheck for private invokeinterface use

[Karen Kinnear]

David,

Really delighted to see you near the end of the major functional changes!

A couple minor comments, and then a question please:

1. MethodHandles.java
 174 different “to” -> different “from” ?
2. methodHandles.cpp
  300-301
  Thank you for the comment.
  Might it also be worth adding that direct call is used by:
    invoke static, invokespecial, invokeinterface:local private, invoke virtual:vfinal and private methods
  (or are you concerned about getting out of sync if this changes?)

3. DirectMethodHandle.java - this was subtle!

I believe this is correct assuming that:
  CallerClass is always and only set for invokespecial. Is this accurate? Could you possibly add a comment?
   - agree with the theory that invokevirtual will never find a private interface method (and ACC_FINAL is illegal for interfaces)

4. Test - I still need to study this
I have been writing down test cases to make sure we don’t test cases we don’t want to, and I
need to double-check you have them covered. Will do that tomorrow. 

thanks,
Karen

> On May 3, 2018, at 6:21 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> bug id: https://bugs.openjdk.java.net/browse/JDK-8197915
> webrev: http://cr.openjdk.java.net/~dholmes/8197915/webrev/
> 
> JDK-8174962 implemented receiver typechecks for invokeinterface within the interpreter (templateTable), compilers and for MethodHandles. In nestmates invokeinterface can now be used for private interface methods - which result in direct calls. So we need to extend the receiver subtype checks to cover the new cases.
> 
> Summary of changes:
> 
> - src/hotspot/cpu/<cpu>/templateTable_<cpu>.cpp
> 
> In the templateTable the 8174962 checks come after the private interface method invocation logic ("vfinal") we already had in place for the nestmate changes, and they rely on itable information that doesn't exist for private methods. So we insert a direct subtype check.
> 
> I've provided code for all CPU's but only x86 and sparc have been tested. I'll be soliciting aid on the other ports before nestmates goes to mainline later this month.
> 
> -  src/hotspot/share/oops/cpCache.cpp
> 
> We have to pass the interface klass* so it's available for the typecheck.
> 
> -  src/hotspot/share/oops/klassVtable.cpp
> 
> Updated a comment that's no longer accurate.
> 
> - src/hotspot/share/opto/doCall.cpp
> 
> This code was provided by Vladimir Ivanov (thank you!) and expands the existing "invokespecial" support for receiver typechecks in C2, to "invokeinterface" as well.
> 
> Aside: no changes were needed for C1. It's seems all the receiver typechecks for C1 are being handled at a higher level (through linkResolver and/or cpCache logic).
> 
> - src/hotspot/share/prims/methodHandles.cpp
> 
> Comment clarifying JVM_REF_invokeSpecial doesn't necessarily mean it relates to an actual "invokespecial" - it is used for all direct calls.
> 
> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
> 
> Add clarifying comments regarding how "kind" can vary if a direct call is involved.
> 
> Expand the condition to switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC (which adds the additional receiver typecheck) to account for the invokeinterface case.
> 
> -  test/jdk/java/lang/invoke/PrivateInterfaceCall.java
> 
> New test for invokeinterface semantics that mirrors the existing SpecialInterfaceCall test for invokespecial.
> 
> This is the last of the significant functional changes for nestmates.
> 
> Thanks,
> David