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

[Erik Osterlund]

Hi John,

So there are two separate problems:

1) The verifier isn’t intelligent enough to catch interface data flow errors because its type system is too simple (a tree, which doesnt reflect the reality of the Java type system), effectively ignoring interfaces. 

2) The compiler can still know things about interfaces, as you describe. But due to the limitations of the verifier, there tends to be confusion around this. As you said, few people know that our own type system can’t be trusted because of that.

So ideally we would at least have an accurate mapping to where we do and do not know about interfaces, knowing the limitations of the verifier. That does not need to entail fixing the verifier, just being more honest in the type system about what we really know vs don’t know.

But ideally we would make the verifier more intelligent to make this whole situation less awkward. For example, maybe a lattice based type system in the verifier that jams in multiple interfaces with Dedekind-MacNeille completion tricks. Perhaps such a lattice based type system would also be more future-proof.
And importantly, then we could trust our own type system, which makes me happy. And I would be utilizing that accuracy.

Thanks,
/Erik


> On 21 Jul 2019, at 02:21, John Rose <john.r.rose at oracle.com> wrote:
> 
> 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
>