CHA for interfaces in C2 compiler
Gustav Åkesson
gustav.r.akesson at gmail.com
Wed Apr 15 14:53:46 UTC 2015
Hi,
I was surprised by this finding after reading Shipilev's blog. In the huge
Java code base I'm currently working in, we have a significant amount of
interfaces with a single implementing class, and hardly any abstract
classes.
>From a use-case perspective I would gladly welcome an attempt to improve
the CHA for interfaces.
Best regards,
Gustav Åkesson
Den 15 apr 2015 16:27 skrev "Vitaly Davidovich" <vitalyd at gmail.com>:
> A heuristic like that would work for most of my cases as well :).
>
> On Wed, Apr 15, 2015 at 10:24 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>>
>> On 04/15/2015 04:10 PM, Vitaly Davidovich wrote:
>>
>>> Hi guys,
>>>
>>> So CHA on classes works nicely in the case of only one subtype loaded.
>>> What about interfaces? Currently, it looks like no such
>>> optimization/analysis is done. In my experience, there's a substantial
>>> amount of code that exposes an interface via some API, but then loads only
>>> implementation of it. The interface is used instead of abstract class to
>>> allow more flexibility in the future.
>>>
>>> I fully realize that lots of interfaces have more than 1 implementer
>>> loaded at runtime, but I also think it's worthwhile to attempt CHA for them.
>>>
>>> Is this something that's feasible to do? It would require more class
>>> loading dependencies to be tracked, but I'm also fine with having this be
>>> an extra flag that I can use to enable/disable this optimization.
>>>
>>> Thoughts?
>>>
>>> Thanks
>>>
>>
>> I've implemented something like this in a language (which has a special
>> syntax for calling Java object).
>> To avoid to have too many metadata, I've used a simple heuristic, the
>> idea is that an interface with a lot of methods do not have a lot of
>> implementations so the runtime only tried to do CHA, using a SwitchPoint,
>> if there were more than 3 methods (included) in the interface.
>>
>> cheers,
>> Rémi
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150415/31e2a77e/attachment.html>
More information about the hotspot-compiler-dev
mailing list