Re: Megamorphic virtual call optimization in Java
Thanks for your responses :)
sobota, 5 lutego 2022 o 18:38:11 UTC+1 Gil Tene napisał(a):
> You might want to give it a spin on Prime (Zing) 11 and see what you get,
> the Falcon JIT in Prime will do polymorphic guarded in-line caching for up
> to 6 implementers by default, I believe (as is configurable to higher if
> needed). This is exactly the sort of thing that capability is meant for.
>
> On Saturday, February 5, 2022 at 1:35:31 AM UTC-10 gros...@gmail.com
> wrote:
>
>> JVM 11+ (OpenJDK / Zulu)
>>
>> sobota, 5 lutego 2022 o 12:30:38 UTC+1 gregor...@gmail.com napisał(a):
>>
>>> which jvm?
>>>
>>> On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
>>>
Hello,
we know that there are some techniques that make virtual calls not so
expensive in JVM like Inline Cache or Polymorphic Inline Cache.
Let's consider the following situation:
Base is an interface.
public void f(Base[] b) {
for(int i = 0; i < b.length; i++) {
b[i].m();
}
}
I see from my profiler that calling virtual (interface) method m is
relatively expensive.
f is on the hot path and it was compiled to machine code (C2) but I
see that call to m is a real virtual call. It means that it was not
optimised by JVM.
The question is, how to deal with a such situation? Obviously, I cannot
make the method m not virtual here because it requires a serious
redesign.
Can I do anything or I have to accept it? I was thinking how to "force"
or "convince" a JVM to
1. use polymorphic inline cache here - the number of different types in
b is quite low - between 4-5 types.
2. to unroll this loop - length of b is also relatively small. After
an unroll it is possible that Inline Cache will be helpful here.
Thanks in advance for any advices.
Regards,
--
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-symp...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
.
>>>
>>>
>>> --
>>> Studying for the Turing test
>>>
>>
--
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/fc7141da-8b5a-4afc-8439-bd1a1fe0ca75n%40googlegroups.com.
Re: Megamorphic virtual call optimization in Java
You might want to give it a spin on Prime (Zing) 11 and see what you get,
the Falcon JIT in Prime will do polymorphic guarded in-line caching for up
to 6 implementers by default, I believe (as is configurable to higher if
needed). This is exactly the sort of thing that capability is meant for.
On Saturday, February 5, 2022 at 1:35:31 AM UTC-10 gros...@gmail.com wrote:
> JVM 11+ (OpenJDK / Zulu)
>
> sobota, 5 lutego 2022 o 12:30:38 UTC+1 gregor...@gmail.com napisał(a):
>
>> which jvm?
>>
>> On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
>>
>>> Hello,
>>> we know that there are some techniques that make virtual calls not so
>>> expensive in JVM like Inline Cache or Polymorphic Inline Cache.
>>>
>>> Let's consider the following situation:
>>>
>>> Base is an interface.
>>>
>>> public void f(Base[] b) {
>>> for(int i = 0; i < b.length; i++) {
>>> b[i].m();
>>> }
>>> }
>>>
>>> I see from my profiler that calling virtual (interface) method m is
>>> relatively expensive.
>>> f is on the hot path and it was compiled to machine code (C2) but I see
>>> that call to m is a real virtual call. It means that it was not
>>> optimised by JVM.
>>>
>>> The question is, how to deal with a such situation? Obviously, I cannot
>>> make the method m not virtual here because it requires a serious
>>> redesign.
>>>
>>> Can I do anything or I have to accept it? I was thinking how to "force"
>>> or "convince" a JVM to
>>>
>>> 1. use polymorphic inline cache here - the number of different types in
>>> b is quite low - between 4-5 types.
>>> 2. to unroll this loop - length of b is also relatively small. After an
>>> unroll it is possible that Inline Cache will be helpful here.
>>>
>>> Thanks in advance for any advices.
>>> Regards,
>>>
>>> --
>>> 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-symp...@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
>>>
>>>
>>> .
>>>
>>
>>
>> --
>> Studying for the Turing test
>>
>
--
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/79ac85ac-73f6-4b7b-b775-85a02f838939n%40googlegroups.com.
Re: Megamorphic virtual call optimization in Java
> From: "r r"
> To: "mechanical-sympathy"
> Sent: Saturday, February 5, 2022 12:20:12 PM
> Subject: Megamorphic virtual call optimization in Java
> Hello,
> we know that there are some techniques that make virtual calls not so
> expensive
> in JVM like Inline Cache or Polymorphic Inline Cache.
> Let's consider the following situation:
> Base is an interface.
> public void f(Base[] b) {
> for(int i = 0; i < b.length; i++) {
> b[i].m();
> }
> }
> I see from my profiler that calling virtual (interface) method m is relatively
> expensive.
> f is on the hot path and it was compiled to machine code (C2) but I see that
> call to m is a real virtual call. It means that it was not optimised by JVM.
> The question is, how to deal with a such situation? Obviously, I cannot make
> the
> method m not virtual here because it requires a serious redesign.
> Can I do anything or I have to accept it? I was thinking how to "force" or
> "convince" a JVM to
> 1. use polymorphic inline cache here - the number of different types in b is
> quite low - between 4-5 types.
> 2. to unroll this loop - length of b is also relatively small. After an unroll
> it is possible that Inline Cache will be helpful here.
I've recently implemented a small library for that kind of stuff.
[ https://github.com/forax/macro | https://github.com/forax/macro ]
The idea is to see b[i].m() or f(Base[] b) as a method call and extract
constants from that method call, the library allows you to choose if a value is
a constant or f(value) is a constant (in case of the array Base[].length is a
constant) and to decide the policy when it's not a real constant (fail, use a
monomorphic inlining cache or use a polymorphic inlining cache).
It uses java.lang.invoke under the hood so everything tend to be inlined.
> Thanks in advance for any advices.
> Regards,
regards,
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/1998782990.10616957.1644061571789.JavaMail.zimbra%40u-pem.fr.
Re: Megamorphic virtual call optimization in Java
JVM 11+ (OpenJDK / Zulu)
sobota, 5 lutego 2022 o 12:30:38 UTC+1 gregor...@gmail.com napisał(a):
> which jvm?
>
> On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
>
>> Hello,
>> we know that there are some techniques that make virtual calls not so
>> expensive in JVM like Inline Cache or Polymorphic Inline Cache.
>>
>> Let's consider the following situation:
>>
>> Base is an interface.
>>
>> public void f(Base[] b) {
>> for(int i = 0; i < b.length; i++) {
>> b[i].m();
>> }
>> }
>>
>> I see from my profiler that calling virtual (interface) method m is
>> relatively expensive.
>> f is on the hot path and it was compiled to machine code (C2) but I see
>> that call to m is a real virtual call. It means that it was not
>> optimised by JVM.
>>
>> The question is, how to deal with a such situation? Obviously, I cannot
>> make the method m not virtual here because it requires a serious
>> redesign.
>>
>> Can I do anything or I have to accept it? I was thinking how to "force"
>> or "convince" a JVM to
>>
>> 1. use polymorphic inline cache here - the number of different types in b
>> is quite low - between 4-5 types.
>> 2. to unroll this loop - length of b is also relatively small. After an
>> unroll it is possible that Inline Cache will be helpful here.
>>
>> Thanks in advance for any advices.
>> Regards,
>>
>> --
>> 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-symp...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
>>
>>
>> .
>>
>
>
> --
> Studying for the Turing test
>
--
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/670d90ee-4b2d-4688-8987-f22646811d1dn%40googlegroups.com.
Re: Megamorphic virtual call optimization in Java
which jvm?
On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
> Hello,
> we know that there are some techniques that make virtual calls not so
> expensive in JVM like Inline Cache or Polymorphic Inline Cache.
>
> Let's consider the following situation:
>
> Base is an interface.
>
> public void f(Base[] b) {
> for(int i = 0; i < b.length; i++) {
> b[i].m();
> }
> }
>
> I see from my profiler that calling virtual (interface) method m is
> relatively expensive.
> f is on the hot path and it was compiled to machine code (C2) but I see
> that call to m is a real virtual call. It means that it was not optimised
> by JVM.
>
> The question is, how to deal with a such situation? Obviously, I cannot
> make the method m not virtual here because it requires a serious
> redesign.
>
> Can I do anything or I have to accept it? I was thinking how to "force" or
> "convince" a JVM to
>
> 1. use polymorphic inline cache here - the number of different types in b
> is quite low - between 4-5 types.
> 2. to unroll this loop - length of b is also relatively small. After an
> unroll it is possible that Inline Cache will be helpful here.
>
> Thanks in advance for any advices.
> Regards,
>
> --
> 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/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
>
> .
>
--
Studying for the Turing test
--
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/CAC9RQthe-HeG8wCOA6TPrzOYw1Z_%3Do%2BDN6BXG7bz5L_fuJxa5A%40mail.gmail.com.
Megamorphic virtual call optimization in Java
Hello,
we know that there are some techniques that make virtual calls not so
expensive in JVM like Inline Cache or Polymorphic Inline Cache.
Let's consider the following situation:
Base is an interface.
public void f(Base[] b) {
for(int i = 0; i < b.length; i++) {
b[i].m();
}
}
I see from my profiler that calling virtual (interface) method m is
relatively expensive.
f is on the hot path and it was compiled to machine code (C2) but I see
that call to m is a real virtual call. It means that it was not optimised
by JVM.
The question is, how to deal with a such situation? Obviously, I cannot
make the method m not virtual here because it requires a serious redesign.
Can I do anything or I have to accept it? I was thinking how to "force" or
"convince" a JVM to
1. use polymorphic inline cache here - the number of different types in b
is quite low - between 4-5 types.
2. to unroll this loop - length of b is also relatively small. After an
unroll it is possible that Inline Cache will be helpful here.
Thanks in advance for any advices.
Regards,
--
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/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com.
