hotspot-compiler-dev Digest, Vol 145, Issue 95

[John Rose]

However we may intend to use interface types, their usefulness is limited
by the fact that they are not preserved across method calls and returns.
That is, method and field signatures which mention interfaces (with the
exception of interfaces as array components) are wishful thinking, and
are effectively aliases for java.lang.Object.

The VM, in its linkage and verification type system, guarantees interfaces
only in limited circumstances

- immediately after a check-cast (of interface type)
- when loading from an array (of interface component)
- on entry to a default method (of the interface, local zero is that type)
- whenever a *class type* is known, and the class implements the interface

But not:

- on entry to a method with an interface parameter (unlike proper classes)
- after return from a method with an interface result (unlike proper classes)
- when loading from an interface-typed field (yes, code can pollute such fields!)
- on entry to a verifier basic block which draws uncertain interface types from predecessor blocks

(Class types are by contract much more rigidly enforced, including in all of the
“but not” cases.)

In those latter “but not" cases, the best we can do in the JIT is to speculate
that the interface type is valid, and issue a dynamic test with an uncommon
trap on speculation failure.  I have never seen any evidence that this would
ever pay off.  (Maybe Erik has an idea or two on that score?)

It’s not widely known, but interface types are almost purely speculative
in the JVM’s static type systems.  Most interfaces are checked only at
the last nanosecond, in the course of an invokeinterface call.  Because this
fact was not fully understood by early JVM engineers, the C2 team invested
much futile effort trying to “trust” interface descriptors, and fixing many bugs
that came from that misplaced trust.  It was all a trail of tears that should have
been avoided.  The source code still bears the scars, in the form of ad hoc
fix-ups that prop up the type checking code on the false theory that “these
types must be worth something, so let’s preserve as much of them as we
can".

— John

> On Jul 20, 2019, at 5:08 PM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> On 18/07/2019 15:35, Erik Österlund wrote:
>> So yeah, I thought I'd just mention that there will be usecases where I
>> will really care about C2 understanding interface types, because I
>> intend to utilize that more than we previously have. So plus one to
>> making C2 understand interface types reliably.
> Hmm, I think the point John is making is that C2 cannot be made
> understand interfaces reliably -- i.e. the problem is to do with the
> nature of interfaces and how they operate in a type system not to do
> with the nature of C2.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander