CHA for interfaces in C2 compiler

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Apr 16 17:11:12 UTC 2015


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
[2] 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>> 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>> wrote:
>      >
>      > That would certainly be a place where removing the type check
>     would be beneficial
>


More information about the hotspot-compiler-dev mailing list