Interface method calls are slow.

[Bryce McKinlay <bryce at albatross dot co dot nz>]

I wrote a small benchmark to time different types of method calls. The code is
available from http://waitaki.otago.ac.nz/~bryce/gcj/meth-inv-bench.tar.gz

The IBM JDK 1.1.8 gets:

no call:          181ms [18ns / call]
local:            287ms [28ns / call]
private:          163ms [16ns / call]
interface:       1506ms [150ns / call]
i/f after cast:   324ms [32ns / call]
abstract:         951ms [95ns / call]
abstract w/cast:  316ms [31ns / call]
native:          4645ms [464ns / call]

While gcj (compiled from source with -O3) gets:

no call:           97ms [9ns / call]
local:            734ms [73ns / call]
private:          606ms [60ns / call]
interface:       5890ms [589ns / call]
i/f after cast:   688ms [68ns / call]
abstract:         686ms [68ns / call]
abstract w/cast:  688ms [68ns / call]
native:           683ms [68ns / call]

I'm not too concerned about the differences between gcj and the VM here -
obviously IBM's JITC is doing a lot of clever optimization that doesn't
neccessarily apply to real-world situations, and maybe cannot even be done by an
ahead-of-time compiler.

BUT...

Why are interface calls so expensive compared to other calls in gcj? I remember
that there was talk a while back about changing the way interface calls are
compiled by gcj - were these change ever made? Slow interface calls will have a
significant impact on the performance of AWT, where every call to a component's
native peer is sent through the interfaces in java.awt.peer. Many other newwer
Java APIs are fairly interface-dependent as well. I am using a current libgcj.

It also appears that the private method call is not being inlined. I thought
that gcj was inlining private methods now?

regards

  [ bryce ]