> From: "r r" <grosi...@gmail.com>
> To: "mechanical-sympathy" <mechanical-sympathy@googlegroups.com>
> 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.
