vcall wish for hotspot

[Clemens Eisserer]

Hi Andy,

> 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
code.

With the alternating sequence of Link1->Link2->Link1 your processor
will detect that each branch is taken with about 50% probability, and
therefore
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
> vtable.
>
> 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
single implementation.

Regards, Clemens

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.