vcall wish for hotspot
linuxhippy at gmail.com
Sun May 19 06:57:26 PDT 2013
> But that could mean that hotspot was now using a vtable, or it could mean
> hotspot was paying for 10 branch mispredictions.
With 2 branch targets ("bimorphic"), hotspots emits the "if/else" you
mentioned including a trap-instruction in case additional classes
implementing the Link interface are loaded later which would trigger
recompilation. A lot of engineering effort was put into optimizing
those cases well, as most function calls are virtual in typical java
With the alternating sequence of Link1->Link2->Link1 your processor
will detect that each branch is taken with about 50% probability, and
it will mispredict about any other branch or so. To factor this out,
warm up the code with a Link1->Link2->Link1 chain, and perform your
benchmark on a chain consisting only of elements of the same type.
> So I tried 20 variants of my Link class, Link1 thru Link20, and hotspot was
> now about 11 nanos. So it would seem that hotspot, for simple variants of a
> base class doesn't use a vtable at all, but just creates one big if-else
> inline. Whereas C++, even with just 2 variants of the class, always uses a
> If this is true, that itself is very interesting. Any ideas how to write a
> test that really forces hotspot to use the vtable?
Hotspot will use a vtable for >= 3 branch targets as far as I know.
For C++ this is most likely compiler specific, but as you can load
additional code in C++ at runtime too and statically C++ code can not
be recompiled at runtime, I guess a C++ compiler has to emit a
vtable-lookup as soon as a virtual function is called even with only a
PS: Take my words with a grain of salt, I am a complete compiler noob.
Looking at the code generated by hotspot is really the best thing you
can do to understand what is going on.
More information about the compiler-dev