CHA for interfaces in C2 compiler
vitalyd at gmail.com
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 oracle.com> wrote:
> There's a more compelling use case for CHA on interfaces .
> That's the case where type profiling fails.
> The other argument to extend CHA for interfaces is to take default methods
> into account .
> Most likely, single interface implementer case you are looking for will
> follow nicely from one of these RFEs.
> But, as noted by Tom in , 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
>  https://bugs.openjdk.java.net/browse/JDK-6986483
>  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...
More information about the hotspot-compiler-dev