CHA for interfaces in C2 compiler

Vitaly Davidovich vitalyd at
Thu Apr 16 18:11:10 UTC 2015

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> 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]
> [2]
> 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
>> <mailto:john.r.rose at>> 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
>>     <mailto:vitalyd at>> wrote:
>>      >
>>      > That would certainly be a place where removing the type check
>>     would be beneficial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-compiler-dev mailing list