Re: does call site polymorphism factor in method overrides?

2019-12-30 Thread Wojciech Kudla 
Hi Brian,

I think I can safely assume your question was dictated by (perfectly valid)
concerns about method dispatch cost in extremely latency sensitive sections
of code. After all, we've used to work together on the same problem space
in the same institution only weeks ago.
Vitaly provided a valuable advice wrt default interface methods however I
would supplement this with a general remark about dispatch cost:

invokeinterface > invokevirtual > invokestatic

(omitted invokespecial and invokedynamic as I have confidence they are
completely out of scope for your case)

For dispatch other than static you'll also have to pay the cost of implicit
null check.
In some cases you can get substantial gains by cheating the runtime and
using instanceof in conjunction with an if-else or switch to invoke a
static method.
If you can test this without committing atrocities on your code base I'd
definitely recommend giving it a try.


On Mon, 30 Dec 2019, 18:09 Remi Forax,  wrote:

>
>
> --
>
> *De: *"Brian Harris" 
> *À: *"mechanical-sympathy" 
> *Envoyé: *Lundi 30 Décembre 2019 17:13:38
> *Objet: *Re: does call site polymorphism factor in method overrides?
>
> Good to know Vitaly!
> So a poor example then. Better example is an abstract class with a method
> implementation that no subtypes override, yet multiple subtypes are found
> to be the receiver of a particular call site. Should we expect a
> monomorphic call site in that case.
>
> On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich 
> wrote:
>
>>
>>
>> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris 
>> wrote:
>>
>>> Hello!
>>> I was hoping to get one point of clarification about avoiding
>>> megamorphic call sites, after reading these excellent articles:
>>>
>>>
>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
>>>
>>> https://shipilev.net/blog/2015/black-magic-method-dispatch/
>>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef
>>>
>>>
>>> When the runtime type of the call receiver is being observed, is it
>>> considered whether that type actually overrides the method in question? For
>>> example, when the method is an interface's default method that none of the
>>> runtime call receivers override, can we expect to get a monomorphic call
>>> site regardless of how many different receiver types are observed at
>>> runtime, given there is only one method body to invoke?
>>>
>> In Hotspot, CHA is currently (AFAIK) disabled for default methods (
>> https://bugs.openjdk.java.net/browse/JDK-8036580).  So you have to be
>> careful putting hot code into them.  Overriding the method in the impl and
>> just calling super will at least restore some performance if type profiling
>> at the callsite helps.
>>
>
> CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm
> not sure you will able be to see any perf difference apart from using a
> micro benchmark.
> And as far as i remember, CHA has never worked for abstract methods and
> nobody care.
>
>
>>> Thanks
>>> Brian
>>>
>>
> Rémi
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAHNMKAqHVvQn3j%3DB0umMGnLWieTVKEXaGAwaHVXSf6rexLDd-g%40mail.gmail.com.

Re: does call site polymorphism factor in method overrides?

2019-12-30 Thread Remi Forax 
> De: "Vitaly Davidovich" 
> À: "mechanical-sympathy" 
> Envoyé: Lundi 30 Décembre 2019 19:43:27
> Objet: Re: does call site polymorphism factor in method overrides?

> On Mon, Dec 30, 2019 at 1:09 PM Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:

>>> De: "Brian Harris" < [ mailto:brianfromore...@gmail.com |
>>> brianfromore...@gmail.com ] >
>>> À: "mechanical-sympathy" < [ mailto:mechanical-sympathy@googlegroups.com |
>>> mechanical-sympathy@googlegroups.com ] >
>>> Envoyé: Lundi 30 Décembre 2019 17:13:38
>>> Objet: Re: does call site polymorphism factor in method overrides?

>>> Good to know Vitaly!
>>> So a poor example then. Better example is an abstract class with a method
>>> implementation that no subtypes override, yet multiple subtypes are found 
>>> to be
>>> the receiver of a particular call site. Should we expect a monomorphic call
>>> site in that case.

>>> On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich < [ 
>>> mailto:vita...@gmail.com
>>> | vita...@gmail.com ] > wrote:

 On Sun, Dec 29, 2019 at 10:22 AM Brian Harris < [
 mailto:brianfromore...@gmail.com | brianfromore...@gmail.com ] > wrote:

> Hello!
> I was hoping to get one point of clarification about avoiding megamorphic 
> call
> sites, after reading these excellent articles:

> [
> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
> |
> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
> ]
> [ https://shipilev.net/blog/2015/black-magic-method-dispatch/ |
> https://shipilev.net/blog/2015/black-magic-method-dispatch/ ]
> [ https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef |
> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef ]

> When the runtime type of the call receiver is being observed, is it 
> considered
> whether that type actually overrides the method in question? For example, 
> when
> the method is an interface's default method that none of the runtime call
> receivers override, can we expect to get a monomorphic call site 
> regardless of
> how many different receiver types are observed at runtime, given there is 
> only
> one method body to invoke?

 In Hotspot, CHA is currently (AFAIK) disabled for default methods (
 [ https://bugs.openjdk.java.net/browse/JDK-8036580 |
 https://bugs.openjdk.java.net/browse/JDK-8036580 ] ). So you have to be 
 careful
 putting hot code into them. Overriding the method in the impl and just 
 calling
 super will at least restore some performance if type profiling at the 
 callsite
 helps.

>> CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm 
>> not
>> sure you will able be to see any perf difference apart from using a micro
>> benchmark.
>> And as far as i remember, CHA has never worked for abstract methods and 
>> nobody
>> care.

> Yeah, I don’t think CHA works for a type-megamorphic callsite that targets the
> same method in the type hierarchy. I might be wrong, but pretty sure Hotspot
> doesn’t handle this case - it ends up being a virtual call if there’s no
> dominant receiver type.

no, you're right. It's a known weakness of c2. But as far as i remember, it 
works with graal. 

> The big (potential) optimization loss here would be inlining; branch + call
> overhead itself is unlikely to matter modulo truly trivial code called in a
> tight loop. Missed optimizations due to inlining failure is the real problem.

> Thanks
> Brian

>> Rémi

Rémi 

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/1385072861.66143.1577732212518.JavaMail.zimbra%40u-pem.fr.

Re: does call site polymorphism factor in method overrides?

2019-12-30 Thread Vitaly Davidovich 
On Mon, Dec 30, 2019 at 1:09 PM Remi Forax  wrote:

>
>
> --
>
> *De: *"Brian Harris" 
> *À: *"mechanical-sympathy" 
> *Envoyé: *Lundi 30 Décembre 2019 17:13:38
> *Objet: *Re: does call site polymorphism factor in method overrides?
>
> Good to know Vitaly!
> So a poor example then. Better example is an abstract class with a method
> implementation that no subtypes override, yet multiple subtypes are found
> to be the receiver of a particular call site. Should we expect a
> monomorphic call site in that case.
>
> On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich 
> wrote:
>
>>
>>
>> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris 
>> wrote:
>>
>>> Hello!
>>> I was hoping to get one point of clarification about avoiding
>>> megamorphic call sites, after reading these excellent articles:
>>>
>>>
>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
>>>
>>> https://shipilev.net/blog/2015/black-magic-method-dispatch/
>>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef
>>>
>>>
>>> When the runtime type of the call receiver is being observed, is it
>>> considered whether that type actually overrides the method in question? For
>>> example, when the method is an interface's default method that none of the
>>> runtime call receivers override, can we expect to get a monomorphic call
>>> site regardless of how many different receiver types are observed at
>>> runtime, given there is only one method body to invoke?
>>>
>> In Hotspot, CHA is currently (AFAIK) disabled for default methods (
>> https://bugs.openjdk.java.net/browse/JDK-8036580).  So you have to be
>> careful putting hot code into them.  Overriding the method in the impl and
>> just calling super will at least restore some performance if type profiling
>> at the callsite helps.
>>
>
> CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm
> not sure you will able be to see any perf difference apart from using a
> micro benchmark.
> And as far as i remember, CHA has never worked for abstract methods and
> nobody care.
>
Yeah, I don’t think CHA works for a type-megamorphic callsite that targets
the same method in the type hierarchy.  I might be wrong, but pretty sure
Hotspot doesn’t handle this case - it ends up being a virtual call if
there’s no dominant receiver type.

The big (potential) optimization loss here would be inlining; branch + call
overhead itself is unlikely to matter modulo truly trivial code called in a
tight loop.  Missed optimizations due to inlining failure is the real
problem.

>
>
>>> Thanks
>>> Brian
>>>
>>
> Rémi
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr
> 
> .
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37F6JT%2BRy2boGAcBEjf6nr4KM_CxF8-Wh5bH6N1eHiph7w%40mail.gmail.com.

Re: does call site polymorphism factor in method overrides?

2019-12-30 Thread Remi Forax 
> De: "Brian Harris" 
> À: "mechanical-sympathy" 
> Envoyé: Lundi 30 Décembre 2019 17:13:38
> Objet: Re: does call site polymorphism factor in method overrides?

> Good to know Vitaly!
> So a poor example then. Better example is an abstract class with a method
> implementation that no subtypes override, yet multiple subtypes are found to 
> be
> the receiver of a particular call site. Should we expect a monomorphic call
> site in that case.

> On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich < [ 
> mailto:vita...@gmail.com
> | vita...@gmail.com ] > wrote:

>> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris < [
>> mailto:brianfromore...@gmail.com | brianfromore...@gmail.com ] > wrote:

>>> Hello!
>>> I was hoping to get one point of clarification about avoiding megamorphic 
>>> call
>>> sites, after reading these excellent articles:

>>> [
>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
>>> |
>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
>>> ]
>>> [ https://shipilev.net/blog/2015/black-magic-method-dispatch/ |
>>> https://shipilev.net/blog/2015/black-magic-method-dispatch/ ]
>>> [ https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef |
>>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef ]

>>> When the runtime type of the call receiver is being observed, is it 
>>> considered
>>> whether that type actually overrides the method in question? For example, 
>>> when
>>> the method is an interface's default method that none of the runtime call
>>> receivers override, can we expect to get a monomorphic call site regardless 
>>> of
>>> how many different receiver types are observed at runtime, given there is 
>>> only
>>> one method body to invoke?

>> In Hotspot, CHA is currently (AFAIK) disabled for default methods (
>> [ https://bugs.openjdk.java.net/browse/JDK-8036580 |
>> https://bugs.openjdk.java.net/browse/JDK-8036580 ] ). So you have to be 
>> careful
>> putting hot code into them. Overriding the method in the impl and just 
>> calling
>> super will at least restore some performance if type profiling at the 
>> callsite
>> helps.

CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm not 
sure you will able be to see any perf difference apart from using a micro 
benchmark. 
And as far as i remember, CHA has never worked for abstract methods and nobody 
care. 

>>> Thanks
>>> Brian

Rémi 

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr.

Re: does call site polymorphism factor in method overrides?

2019-12-30 Thread Brian Harris 
Good to know Vitaly!

So a poor example then. Better example is an abstract class with a method
implementation that no subtypes override, yet multiple subtypes are found
to be the receiver of a particular call site. Should we expect a
monomorphic call site in that case.

On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich 
wrote:

>
>
> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris 
> wrote:
>
>> Hello!
>>
>> I was hoping to get one point of clarification about avoiding megamorphic
>> call sites, after reading these excellent articles:
>>
>>
>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
>>
>> https://shipilev.net/blog/2015/black-magic-method-dispatch/
>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef
>>
>>
>> When the runtime type of the call receiver is being observed, is it
>> considered whether that type actually overrides the method in question? For
>> example, when the method is an interface's default method that none of the
>> runtime call receivers override, can we expect to get a monomorphic call
>> site regardless of how many different receiver types are observed at
>> runtime, given there is only one method body to invoke?
>>
> In Hotspot, CHA is currently (AFAIK) disabled for default methods (
> https://bugs.openjdk.java.net/browse/JDK-8036580).  So you have to be
> careful putting hot code into them.  Overriding the method in the impl and
> just calling super will at least restore some performance if type profiling
> at the callsite helps.
>
>>
>> Thanks
>> Brian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/CAFtUM9Zt%2BwJvkDix_ZEYA%2B5u6hA86VQW7d5ceEyvxetiLvq%2BfA%40mail.gmail.com
>> 
>> .
>>
> --
> Sent from my phone
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37EiQQKRfJvm3AVv87DiUpimxckyTVTtHRxgZDYUhfMC4g%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAFtUM9a-gFquj%3DUmQLHZuXSui9neBOsCTLF9E_KdOt%2B_4AaATQ%40mail.gmail.com.