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

[John Rose]

On May 9, 2018, at 2:29 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
>> 
>> All I can say is that processing CharSequence.toString ends up in set_direct_or_vtable_call with invokeinterface. In mainline that takes the change_to_virtual path. I discovered this when I tried to add overly strong assertions to the code paths.
> Thanks. Been wondering about that one for years.
> Calling LinkResolver for invokeinterface, we discover that CharSequence.toString has a vtable index because the public abstract toString()
> method overrides a java.lang.Object method and therefore needs to be treated relative to a vtable index rather than ani table index.
> A given method only gets one or the other.

I remember when I realized that the JVM does that,
and that the supposed clean difference between
invokevirtual and invokeinterface is a fiction,
in the following sense:  Just as invokevirtual can
strength-reduce to the equivalent of invokespecial
(we call this the "vfinal" mode in the CPC), so also
can invokeinterface strength-reduce to invokevirtual,
when it is called on toString, equals, or hashCode.
In fact, invokeinterface can go all the down and set
the "vfinal" mode bit, effectively turning itself into
invokespecial.  This happens when it is called on
getClass, wait, notify, etc.

So, as far as method linkage is concerned, there are
indeed three modes, but invokeinterface can link to
all three, while invokevirtual can link to all but one.

This is why direct method handles have that confusing
treatment of invokes, where sometimes you get special
linkage mode when you asked the Lookup for something else.
You can also get virtual linkage mode when you ask the
Lookup for an interface method.  But the Lookup doesn't
have a separate findVirtual method, again because the
difference between interface methods and class methods
are not deep enough to justify the extra Lookup API point.

— John