CHA for interfaces in C2 compiler

[Vitaly Davidovich]

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> 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
> [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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150416/98a39445/attachment-0001.html>