CHA for interfaces in C2 compiler

[Vladimir Ivanov]

I don't think it's a problem, but one of peculiarities how Java bytecode 
verification algorithm works. Current approach (interface type erasure 
to Object) allows considerable simplification of verification algorithm, 
but VM is obliged to do more runtime checks.

[1] ($3.3) has a good overview of the problems with verification of 
interface types in Java bytecode.

Probably, we'll get a chance to reconsider that choice in the future.

Best regards,
Vladimir Ivanov

[1] 
http://www-master.ufr-info-p6.jussieu.fr/2005/IMG/pdf/leroy-bytecode-verification-JAR.pdf

On 4/16/15 9:11 PM, Vitaly Davidovich wrote:
> Hmm, I didn't know that bc verifier doesn't verify interfaces.  Is that
> an open problem at the moment?
>
> Sounds like interfaces just get the short end of the stick all around :).
>
> On Thu, Apr 16, 2015 at 1:11 PM, Vladimir Ivanov
> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> wrote:
>
>     There's a more compelling use case for CHA on interfaces [1].
>     That's the case where type profiling fails.
>
>     The other argument to extend CHA for interfaces is to take default
>     methods into account [2].
>
>     Most likely, single interface implementer case you are looking for
>     will follow nicely from one of these RFEs.
>
>     But, as noted by Tom in [1], CHA doesn't allow to reliably eliminate
>     the type check for interfaces (since bytecode verifier doesn't
>     provide type safety guarantees for interfaces). Except the array
>     case, where type check happens during array store and JIT can skip
>     rely on that.
>
>     Best regards,
>     Vladimir Ivanov
>
>     [1] https://bugs.openjdk.java.net/__browse/JDK-6986483
>     <https://bugs.openjdk.java.net/browse/JDK-6986483>
>     [2] https://bugs.openjdk.java.net/__browse/JDK-8036580
>     <https://bugs.openjdk.java.net/browse/JDK-8036580>
>
>     On 4/16/15 1:24 PM, Vitaly Davidovich wrote:
>
>         I'd argue that the cacheline fetch is more of an issue when not
>         dealing
>         with array iteration but with the "islands" I was referring to
>         earlier.
>         In the array iteration scenario, the actual method invoked may
>         be less
>         expensive than the type check.  Yes, the branch will be
>         predicted and
>         all, but that's still extra code that will execute, extra entry
>         in the
>         BTB, etc.
>
>         Maybe you guys aren't convinced, but do realize that there's
>         plenty of
>         code out there with the "one impl of an interface loaded" situation.
>         Every small efficiency gain counts, IMO.
>
>         sent from my phone
>
>         On Apr 16, 2015 2:56 AM, "John Rose" <john.r.rose at oracle.com
>         <mailto:john.r.rose at oracle.com>
>         <mailto:john.r.rose at oracle.com
>         <mailto:john.r.rose at oracle.com>__>> wrote:
>
>              The real cost of the type check is a cache line fetch. In
>         this case
>              you have a bunch of objects whose code is the same
>         method(s) and
>              data fields are the only way to vary the behavior. So
>         almost any
>              plausible application of this pattern will need the same
>         cache line
>              as the data fields.
>
>              We have yet to see a convincing use case for this CHA (THA)
>         case.  I
>              put some code in the VM to support this once but we never
>         needed it
>              and it was removed.
>
>              (Another opt with a similar flavor would be support for the
>              singleton pattern.)
>
>              – John
>
>               > On Apr 15, 2015, at 8:05 PM, Vitaly Davidovich
>         <vitalyd at gmail.com <mailto:vitalyd at gmail.com>
>              <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>>> wrote:
>               >
>               > That would certainly be a place where removing the type
>         check
>              would be beneficial
>
>