RFR(M): 8141551: C2 can not handle returns with incompatible interface arrays

[John Rose]

Ughh, that again.  This is 15-year-old technical debt in the C2 type system.
It has almost earned VP-level recognition as an organizational cost center.

Here is some of the trail of tears:
https://bugs.openjdk.java.net/browse/JDK-6312651 <https://bugs.openjdk.java.net/browse/JDK-6312651>
https://bugs.openjdk.java.net/browse/JDK-4641534 <https://bugs.openjdk.java.net/browse/JDK-4641534>
https://bugs.openjdk.java.net/browse/JDK-6837094 <https://bugs.openjdk.java.net/browse/JDK-6837094>
https://bugs.openjdk.java.net/browse/JDK-8028165?focusedCommentId=13614504&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13614504 <https://bugs.openjdk.java.net/browse/JDK-8028165?focusedCommentId=13614504&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13614504>

There are two related confusions:  1. When the code was written, almost nobody understood that interface names in bytecode must be treated as aspirations, something that is hoped to be true but cannot be relied on.  So we coded them as if they were reliable types, and then patched forever around the spots where that assumption got us into trouble.  2. Multiply-inherited types like interfaces can be made into a lattice, but only if your lattice labels are *sets* of type names, instead of single class names.  The second point is not confusing after a few moments of thought, but we rarely got that far due to confusion #1.  Nowt, nobody wants to touch the code, except when they are forced to patch it up a little more.

Up-leveling a bit, here's what a type system designer has to remember, at least when working in an optimizer like C2:  A type is not only an ideal (extensional) subset of a universe of runtime values, but it is an (intension) assertion about every value that may eventually bind to the typed entity.  The extensional structure is pleasant to visualize in an ad hoc manner, and it turns into a venn-like lattice diagram, but the intensional structure is much easier to reason about, since it factors easily into discrete propositions.  TypeInt(2,5) embodies the assertions {x:int32, x>=2, x<=5} (plus a bunch of trivial corollaries).  TypeInstPtr(String) embodies assertions {x:oop, x instanceof String, x instanceof Object}, and the last is a trivial corollary of the second.  If we want to support true interface typing, we need to implement assertion sets like this {x:oop, x instanceof Serializable, x instanceof Type}.

All this is to say that, while I understand that fixes like the present one are needed, they amount to rest stops on the Road of Good Intentions to You Know Where.  We need a deeper fix.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151111/56f1bffc/attachment.html>