Too Fast, Too Megamorphic: what influences method call performance in Java?

whats this all about then?

let’s start with a short story. a few weeks back i proposed a change on the a java core libs mailing list to override some methods which are currently final . this stimulated several discussion topics - one of which was the extent to which a performance regression would be introduced by taking a method which was final and stopping it from being final .

i had some ideas about whether there would be a performance regression or not, but i put these aside to try and enquire as to whether there were any sane benchmarks published on the subject. unfortunately i couldn’t find any. that’s not to say that they don’t exist or that other people haven’t investigated the situation, but that i didn't see any public peer-reviewed code. so - time to write some benchmarks.

benchmarking methodology

so i decided to use the ever-awesome jmh framework in order to put together these benchmarks. if you aren't convinced that a framework will help you get accurate benchmarking results then you should look at this talk by aleksey shipilev , who wrote the framework, or nitsan wakart's really cool blog post which explains how it helps.

in my case i wanted to understand what influenced the performance of method invocation. i decided to try out different variations of methods calls and measure the cost. by having a set of benchmarks and changing only one factor at a time, we can individually rule out or understand how different factors or combinations of factors influence method invocation costs.

inlining

let's squish these method callsites down.

simultaneously the most and least obvious influencing factor is whether there is a method call at all! it's possible for the actual cost of a method call to be optimized away entirely by the compiler. there are, broadly speaking, two ways to reduce the cost of the call. one is to directly inline the method itself, the other is to use an inline cache. don't worry - these are pretty simple concepts but there's a bit of terminology involved which needs to be introduced. let's pretend that we have a class called foo , which defines a method called bar .

class foo {
  void bar() { ... }
}

we can call the bar method by writing code that looks like this:

foo foo = new foo();
foo.bar();

the important thing here is the location where bar is actually invoked - foo.bar() - this is referred to as a callsite . when we say a method is being "inlined" what is means is that the body of the method is taken and plopped into the callsite, in place of a method call. for programs which consist of lots of small methods (i'd argue, a properly factored program) the inlining can result in a significant speedup. this is because the program doesn't end up spending most of its time calling methods and not actually doing work! we can control whether a method is inlined or not in jmh by using the compilercontrol annotations. we'll come back to the concept of an inline cache a bit later.

hierarchy depth and overriding methods

do parents slow their children down?

if we're choosing to remove the final keyword from a method it means that we'll be able to override it. this is another factor which we consequently need to take into account. so i took methods and called them at different levels of a class hierarchy and also had methods which were overridden at different levels of the hierarchy. this allowed me to understand or eliminate how deep class hierarchies interfere with overriding costs.

polymorphism

animals: how any oo concept is described.

when i mentioned the idea of a callsite earlier i sneakily avoided a fairly important issue. since it's possible to override a non- final method in a subclass, our callsites can end up invoking different methods. so perhaps i pass in a foo or it's child - baz - which also implements a bar(). how does your compiler know which method to invoke? methods are by default virtual (overridable) in java it has to lookup the correct method in a table, called a vtable, for every invocation. this is pretty slow, so optimizing compilers are always trying to reduce the lookup costs involved. one approach we mentioned earlier is inlining, which is great if your compiler can prove that only one method can be called at a given callsite. this is called a monomorphic callsite.

unfortunately much of the time the analysis required to prove a callsite is monomorphic can end up being impractical. jit compilers tend to take an alternative approach of profiling which types are called at a callsite and guessing that if the callsite has been monomorphic for it's first n calls then it's worth speculatively optimising based on the assumption that it always will be monomorphic. this speculative optimisation is frequently correct, but because it's not always right the compiler needs to inject a guard before the method call in order to check the type of the method.

monomorphic callsites aren't the only case we want to optimise for though. many callsites are what is termed bimorphic - there are two methods which can be invoked. you can still inline bimorphic callsites by using your guard code to check which implementation to call and then jumping to it. this is still cheaper than a full method invocation. it's also possible to optimise this case using an inline cache. an inline cache doesn't actually inline the method body into a callsite but it has a specialised jump table which acts like a cache on a full vtable lookup. the hotspot jit compiler supports bimorphic inline caches and declares that any callsite with 3 or more possible implementations is megamorphic .

this splits out 3 more invocation situations for us to benchmark and investigate: the monomorphic case, the bimorphic case and the megamorphic case.

results

let's groups up results so it's easier to see the wood from the trees, i've presented the raw numbers along with a bit of analysis around them. the specific numbers/costs aren't really of that much interest. what is interesting is the ratios between different types of method call and that the associated error rates are low. there's quite a significant difference going on - 6.26x between the fastest and slowest. in reality the difference is probably larger because of the overhead associated with measuring the time of an empty method.

the source code for these benchmarks is available on github . the results aren't all presented in one block to avoid confusion. the polymorphic benchmarks at the end come from running polymorphicbenchmark , whilst the others are from javafinalbenchmark

simple callsites

benchmark                                                    mode   samples         mean   mean error    units
c.i.j.javafinalbenchmark.finalinvoke                         avgt        25        2.606        0.007    ns/op
c.i.j.javafinalbenchmark.virtualinvoke                       avgt        25        2.598        0.008    ns/op
c.i.j.javafinalbenchmark.alwaysoverriddenmethod              avgt        25        2.609        0.006    ns/op

our first set of results compare the call costs of a virtual method, a final method and a method which has a deep hierarchy and gets overridden. note that in all these cases we've forced the compiler to not inline the methods. as we can see the difference between the times is pretty minimal and and our mean error rates show it to be of no great importance. so we can conclude that simply adding the final keyword isn't going to drastically improve method call performance. overriding the method also doesn't seem to make much difference either.

inlining simple callsites

benchmark                                                    mode   samples         mean   mean error    units
c.i.j.javafinalbenchmark.inlinablefinalinvoke                avgt        25        0.782        0.003    ns/op
c.i.j.javafinalbenchmark.inlinablevirtualinvoke              avgt        25        0.780        0.002    ns/op
c.i.j.javafinalbenchmark.inlinablealwaysoverriddenmethod     avgt        25        1.393        0.060    ns/op

now, we've taken the same three cases and removed the inlining restriction. again the final and virtual method calls end up being of a similar time to each other. they are about 4x faster than the non-inlineable case, which i would put down to the inlining itself. the always overridden method call here ends up being between the two. i suspect that this is because the method itself has multiple possible subclass implementations and consequently the compiler needs to insert a type guard. the mechanics of this are explained above in more detail under polymorphism .

class hierachy impact

benchmark                                                    mode   samples         mean   mean error    units
c.i.j.javafinalbenchmark.parentmethod1                       avgt        25        2.600        0.008    ns/op
c.i.j.javafinalbenchmark.parentmethod2                       avgt        25        2.596        0.007    ns/op
c.i.j.javafinalbenchmark.parentmethod3                       avgt        25        2.598        0.006    ns/op
c.i.j.javafinalbenchmark.parentmethod4                       avgt        25        2.601        0.006    ns/op
c.i.j.javafinalbenchmark.inlinableparentmethod1              avgt        25        1.373        0.006    ns/op
c.i.j.javafinalbenchmark.inlinableparentmethod2              avgt        25        1.368        0.004    ns/op
c.i.j.javafinalbenchmark.inlinableparentmethod3              avgt        25        1.371        0.004    ns/op
c.i.j.javafinalbenchmark.inlinableparentmethod4              avgt        25        1.371        0.005    ns/op

wow - that's a big block of methods! each of the numbered method calls (1-4) refer to how deep up a class hierarchy a method was invoked upon. so parentmethod4 means we called a method declared on the 4th parent of the class. if you look at the numbers there is very little difference between 1 and 4. so we can conclude that hierarchy depth makes no difference. the inlineable cases all follow the same pattern: hierarchy depth makes no difference. our inlineable method performance is comparable to inlinablealwaysoverriddenmethod , but slower than inlinablevirtualinvoke . i would again put this down to the type guard being used. the jit compiler can profile the methods to figure out only one is inlined, but it can't prove that this holds forever.

class hierachy impact on final methods

benchmark                                                    mode   samples         mean   mean error    units
c.i.j.javafinalbenchmark.parentfinalmethod1                  avgt        25        2.598        0.007    ns/op
c.i.j.javafinalbenchmark.parentfinalmethod2                  avgt        25        2.596        0.007    ns/op
c.i.j.javafinalbenchmark.parentfinalmethod3                  avgt        25        2.640        0.135    ns/op
c.i.j.javafinalbenchmark.parentfinalmethod4                  avgt        25        2.601        0.009    ns/op
c.i.j.javafinalbenchmark.inlinableparentfinalmethod1         avgt        25        1.373        0.004    ns/op
c.i.j.javafinalbenchmark.inlinableparentfinalmethod2         avgt        25        1.375        0.016    ns/op
c.i.j.javafinalbenchmark.inlinableparentfinalmethod3         avgt        25        1.369        0.005    ns/op
c.i.j.javafinalbenchmark.inlinableparentfinalmethod4         avgt        25        1.371        0.003    ns/op

this follows the same pattern as above - the final keyword seems to make no difference. i would have thought it was possible here, theoretically, for inlinableparentfinalmethod4 to be proved inlineable with no type guard but it doesn't appear to be the case.

polymorphism

monomorphic: 2.816 +- 0.056 ns/op
bimorphic: 3.258 +- 0.195 ns/op
megamorphic: 4.896 +- 0.017 ns/op
inlinable monomorphic: 1.555 +- 0.007 ns/op
inlinable bimorphic: 1.555 +- 0.004 ns/op
inlinable megamorphic: 4.278 +- 0.013 ns/op

finally we come to the case of polymorphic dispatch. monomorphoric call costs are roughly the same as our regular virtual invoke call costs above. as we need to do lookups on larger vtables, they become slower as the bimorphic and megamorphic cases show. once we enable inlining the type profiling kicks in and our monomorphic and bimorphic callsites come down the cost of our "inlined with guard" method calls. so similar to the class hierarchy cases, just a bit slower. the megamorphic case is still very slow. remember that we've not told hotspot to prevent inlining here, it just doesn't implement polymorphic inline cache for callsites more complex than bimorphic.

what did we learn?

i think it's worth noting that there are plenty of people who don't have a performance mental model that accounts for different types of method calls taking different amounts of time and plenty of people who understand they take different amounts of time but don't really have it quite right. i know i've been there before and made all sorts of bad assumptions. so i hope this investigation has been helpful to people. here's a summary of claims i'm happy to stand by.

• there is a big difference between the fastest and slowest types of method invocation.
• in practice the addition or removal of the final keyword doesn't really impact performance, but, if you then go and refactor your hierarchy things can start to slow down.
• deeper class hierarchies have no real influence on call performance.
• monomorphic calls are faster than bimorphic calls.
• bimorphic calls are faster than megamorphic calls.
• the type guard that we see in the case of profile-ably, but not provably, monomorphic callsites does slow things down quite a bit over a provably monomorphic callsite.

i would say that the cost of the type guard is my personal "big revelation". it's something that i rarely see talked about and often dismissed as being irrelevant.

caveats and further work

of course this isn't a conclusive treatment of the topic area!

• this blog has just focussed on type related factors surrounding method invoke performance. one factor i've not mentioned is the heuristics surrounding method inlining due to body size or call stack depth. if your method is too large it won't get inlined at all, and you'll still end up paying for the cost of the method call. yet another reason to write small, easy to read, methods.
• i've not looked into how invoking over an interface affects any of these situations. if you've found this interesting then there's an investigation of invoke interface performance on the mechanical sympathy blog.
• one factor that we've completely ignored here is the impact of method inlining on other compiler optimisations. when compilers are performing optimisations which only look at one method (intra-procedural optimisation) they really want as much information as they can get in order to optimize effectively. the limitations of inlining can significantly reduce the scope that other optimisations have to work with.
• tying the explanation right down to the assembly level to dive into more detail on the issue.

perhaps these are topics for a future blog post.

thanks to aleksey shipilev for feedback on the benchmarks and to martin thompson , aleksey, martijn verburg , sadiq jaffer and chris west for the very helpful feedback on the blog post.