Quantcast

[10] RFR (M): 6986483: CHA: optimize calls through interfaces

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vladimir Ivanov
http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-6986483

Proposed change adds CHA support in C2 for interface calls.

Consider the following hierarchy:

   interface Intf { m(); }
   class C implements Intf { public m() { ... } }
   class C1 extends C { /* doesn't override m() */ }
   ...
   class Cn extends C { /* doesn't override m() */ }

Call site: invokeinterface Intf.m() ...

If Intf were an abstract class, CHA could deduce that Intf::m() can be
replaced with C::m(), but it doesn't work for interfaces. Verifier
doesn't check interface types in bytecode, so CHA can't assume the
receiver implements Intf.

CHA in C1 handles such call sites for interfaces with a single
implementor. It replaces invokeinterface Intf.m() with invokevirtual
C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and
this request is about adding that. Type profiling doesn't help here (the
call site is usually megamorphic), so C2 can't inline it.

The proposed implementation is similar to C1, except that the code
deoptimizes when subtype check fails and ICCE is thrown from the
interpreter.

While working on it, I spotted and fixed a couple of inefficiencies in
C1 implementation:

   (1) dependency context being used was broader than necessary -
resolved instead of declared interface (hence, possibility of
unnecessary invalidations);

   (2) didn't work for interfaces w/ any default methods: CHA doesn't
support default methods at the moment, so what matters is whether
Intf::m() is default or not and not whether Intf has *any* concrete methods.

Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress),
LogCompilation tool.

Thanks!

Best regards,
Vladimir Ivanov
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vladimir Kozlov
Seems fine to me.

thanks,
Vladimir K

On 2/14/17 10:51 AM, Vladimir Ivanov wrote:

> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-6986483
>
> Proposed change adds CHA support in C2 for interface calls.
>
> Consider the following hierarchy:
>
>   interface Intf { m(); }
>   class C implements Intf { public m() { ... } }
>   class C1 extends C { /* doesn't override m() */ }
>   ...
>   class Cn extends C { /* doesn't override m() */ }
>
> Call site: invokeinterface Intf.m() ...
>
> If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume
> the receiver implements Intf.
>
> CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that
> and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it.
>
> The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter.
>
> While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation:
>
>   (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations);
>
>   (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any*
> concrete methods.
>
> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Paul Sandoz
In reply to this post by Vladimir Ivanov
Hi,

This is a nice surprise :-)

I happened to be separately looking at this area, analysing the performance of interfaces/abstract classes to apply a certain implementation technique to avoid going megamorphic.

I concluded that the implementation technique was not viable, but with your patch i think i can revive it and perform more detailed analysis.

Based on my benchmark the performance improvement looks good.

Thanks!
Paul.

> On 14 Feb 2017, at 10:51, Vladimir Ivanov <[hidden email]> wrote:
>
> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-6986483
>
> Proposed change adds CHA support in C2 for interface calls.
>
> Consider the following hierarchy:
>
>  interface Intf { m(); }
>  class C implements Intf { public m() { ... } }
>  class C1 extends C { /* doesn't override m() */ }
>  ...
>  class Cn extends C { /* doesn't override m() */ }
>
> Call site: invokeinterface Intf.m() ...
>
> If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf.
>
> CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it.
>
> The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter.
>
> While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation:
>
>  (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations);
>
>  (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods.
>
> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vitaly Davidovich

On Thu, Feb 16, 2017 at 3:00 PM Paul Sandoz <[hidden email]> wrote:
Hi,

This is a nice surprise :-)
+1 - great work Vladimir! I didn't know C1 handled this already - always thought it's no better than C2 in any performance aspect :).

A bit premature to ask perhaps, but could this conceivably be backported to Java 9?


I happened to be separately looking at this area, analysing the performance of interfaces/abstract classes to apply a certain implementation technique to avoid going megamorphic.

I concluded that the implementation technique was not viable, but with your patch i think i can revive it and perform more detailed analysis.

Based on my benchmark the performance improvement looks good.

Thanks!
Paul.

> On 14 Feb 2017, at 10:51, Vladimir Ivanov <[hidden email]> wrote:
>
> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-6986483
>
> Proposed change adds CHA support in C2 for interface calls.
>
> Consider the following hierarchy:
>
>  interface Intf { m(); }
>  class C implements Intf { public m() { ... } }
>  class C1 extends C { /* doesn't override m() */ }
>  ...
>  class Cn extends C { /* doesn't override m() */ }
>
> Call site: invokeinterface Intf.m() ...
>
> If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf.
>
> CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it.
>
> The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter.
>
> While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation:
>
>  (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations);
>
>  (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods.
>
> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vladimir Ivanov
In reply to this post by Vladimir Kozlov
Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 2/15/17 11:38 PM, Vladimir Kozlov wrote:

> Seems fine to me.
>
> thanks,
> Vladimir K
>
> On 2/14/17 10:51 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-6986483
>>
>> Proposed change adds CHA support in C2 for interface calls.
>>
>> Consider the following hierarchy:
>>
>>   interface Intf { m(); }
>>   class C implements Intf { public m() { ... } }
>>   class C1 extends C { /* doesn't override m() */ }
>>   ...
>>   class Cn extends C { /* doesn't override m() */ }
>>
>> Call site: invokeinterface Intf.m() ...
>>
>> If Intf were an abstract class, CHA could deduce that Intf::m() can be
>> replaced with C::m(), but it doesn't work for interfaces. Verifier
>> doesn't check interface types in bytecode, so CHA can't assume
>> the receiver implements Intf.
>>
>> CHA in C1 handles such call sites for interfaces with a single
>> implementor. It replaces invokeinterface Intf.m() with invokevirtual
>> C.m() guarded by a subtype check (instanceof C). C2 doesn't do that
>> and this request is about adding that. Type profiling doesn't help
>> here (the call site is usually megamorphic), so C2 can't inline it.
>>
>> The proposed implementation is similar to C1, except that the code
>> deoptimizes when subtype check fails and ICCE is thrown from the
>> interpreter.
>>
>> While working on it, I spotted and fixed a couple of inefficiencies in
>> C1 implementation:
>>
>>   (1) dependency context being used was broader than necessary -
>> resolved instead of declared interface (hence, possibility of
>> unnecessary invalidations);
>>
>>   (2) didn't work for interfaces w/ any default methods: CHA doesn't
>> support default methods at the moment, so what matters is whether
>> Intf::m() is default or not and not whether Intf has *any*
>> concrete methods.
>>
>> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress),
>> LogCompilation tool.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vladimir Ivanov
In reply to this post by Vitaly Davidovich
Vitaly,

> A bit premature to ask perhaps, but could this conceivably be backported
> to Java 9?
Yes, once it gets enough testing in jdk10 repo I'll consider backporting
it into upcoming 9u release.

No chances to get it into jdk9 GA though.

Best regards,
Vladimir Ivanov

>
>     I happened to be separately looking at this area, analysing the
>     performance of interfaces/abstract classes to apply a certain
>     implementation technique to avoid going megamorphic.
>
>     I concluded that the implementation technique was not viable, but
>     with your patch i think i can revive it and perform more detailed
>     analysis.
>
>     Based on my benchmark the performance improvement looks good.
>
>     Thanks!
>     Paul.
>
>     > On 14 Feb 2017, at 10:51, Vladimir Ivanov
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>     >
>     > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
>     > https://bugs.openjdk.java.net/browse/JDK-6986483
>     >
>     > Proposed change adds CHA support in C2 for interface calls.
>     >
>     > Consider the following hierarchy:
>     >
>     >  interface Intf { m(); }
>     >  class C implements Intf { public m() { ... } }
>     >  class C1 extends C { /* doesn't override m() */ }
>     >  ...
>     >  class Cn extends C { /* doesn't override m() */ }
>     >
>     > Call site: invokeinterface Intf.m() ...
>     >
>     > If Intf were an abstract class, CHA could deduce that Intf::m()
>     can be replaced with C::m(), but it doesn't work for interfaces.
>     Verifier doesn't check interface types in bytecode, so CHA can't
>     assume the receiver implements Intf.
>     >
>     > CHA in C1 handles such call sites for interfaces with a single
>     implementor. It replaces invokeinterface Intf.m() with invokevirtual
>     C.m() guarded by a subtype check (instanceof C). C2 doesn't do that
>     and this request is about adding that. Type profiling doesn't help
>     here (the call site is usually megamorphic), so C2 can't inline it.
>     >
>     > The proposed implementation is similar to C1, except that the code
>     deoptimizes when subtype check fails and ICCE is thrown from the
>     interpreter.
>     >
>     > While working on it, I spotted and fixed a couple of
>     inefficiencies in C1 implementation:
>     >
>     >  (1) dependency context being used was broader than necessary -
>     resolved instead of declared interface (hence, possibility of
>     unnecessary invalidations);
>     >
>     >  (2) didn't work for interfaces w/ any default methods: CHA
>     doesn't support default methods at the moment, so what matters is
>     whether Intf::m() is default or not and not whether Intf has *any*
>     concrete methods.
>     >
>     > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in
>     progress), LogCompilation tool.
>     >
>     > Thanks!
>     >
>     > Best regards,
>     > Vladimir Ivanov
>
> --
> Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vitaly Davidovich


On Wed, Feb 22, 2017 at 9:47 AM, Vladimir Ivanov <[hidden email]> wrote:
Vitaly,

A bit premature to ask perhaps, but could this conceivably be backported
to Java 9?
Yes, once it gets enough testing in jdk10 repo I'll consider backporting it into upcoming 9u release.

No chances to get it into jdk9 GA though.
Sounds great - thanks! 

Best regards,
Vladimir Ivanov


    I happened to be separately looking at this area, analysing the
    performance of interfaces/abstract classes to apply a certain
    implementation technique to avoid going megamorphic.

    I concluded that the implementation technique was not viable, but
    with your patch i think i can revive it and perform more detailed
    analysis.

    Based on my benchmark the performance improvement looks good.

    Thanks!
    Paul.

    > On 14 Feb 2017, at 10:51, Vladimir Ivanov
    <[hidden email] <mailto:[hidden email]>>

    wrote:
    >
    > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
    > https://bugs.openjdk.java.net/browse/JDK-6986483
    >
    > Proposed change adds CHA support in C2 for interface calls.
    >
    > Consider the following hierarchy:
    >
    >  interface Intf { m(); }
    >  class C implements Intf { public m() { ... } }
    >  class C1 extends C { /* doesn't override m() */ }
    >  ...
    >  class Cn extends C { /* doesn't override m() */ }
    >
    > Call site: invokeinterface Intf.m() ...
    >
    > If Intf were an abstract class, CHA could deduce that Intf::m()
    can be replaced with C::m(), but it doesn't work for interfaces.
    Verifier doesn't check interface types in bytecode, so CHA can't
    assume the receiver implements Intf.
    >
    > CHA in C1 handles such call sites for interfaces with a single
    implementor. It replaces invokeinterface Intf.m() with invokevirtual
    C.m() guarded by a subtype check (instanceof C). C2 doesn't do that
    and this request is about adding that. Type profiling doesn't help
    here (the call site is usually megamorphic), so C2 can't inline it.
    >
    > The proposed implementation is similar to C1, except that the code
    deoptimizes when subtype check fails and ICCE is thrown from the
    interpreter.
    >
    > While working on it, I spotted and fixed a couple of
    inefficiencies in C1 implementation:
    >
    >  (1) dependency context being used was broader than necessary -
    resolved instead of declared interface (hence, possibility of
    unnecessary invalidations);
    >
    >  (2) didn't work for interfaces w/ any default methods: CHA
    doesn't support default methods at the moment, so what matters is
    whether Intf::m() is default or not and not whether Intf has *any*
    concrete methods.
    >
    > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in
    progress), LogCompilation tool.
    >
    > Thanks!
    >
    > Best regards,
    > Vladimir Ivanov

--
Sent from my phone

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR (M): 6986483: CHA: optimize calls through interfaces

Vladimir Ivanov
In reply to this post by Paul Sandoz
> Based on my benchmark the performance improvement looks good.

Glad to hear that, Paul. Thanks for verifying.

Best regards,
Vladimir Ivanov

>> On 14 Feb 2017, at 10:51, Vladimir Ivanov <[hidden email]> wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-6986483
>>
>> Proposed change adds CHA support in C2 for interface calls.
>>
>> Consider the following hierarchy:
>>
>>  interface Intf { m(); }
>>  class C implements Intf { public m() { ... } }
>>  class C1 extends C { /* doesn't override m() */ }
>>  ...
>>  class Cn extends C { /* doesn't override m() */ }
>>
>> Call site: invokeinterface Intf.m() ...
>>
>> If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf.
>>
>> CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it.
>>
>> The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter.
>>
>> While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation:
>>
>>  (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations);
>>
>>  (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods.
>>
>> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>
Loading...