CHA for interfaces in C2 compiler

Gustav Åkesson gustav.r.akesson at
Wed Apr 15 14:53:46 UTC 2015


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

>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>:

> 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> 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: <>

More information about the hotspot-compiler-dev mailing list