In certain combinations of platform and engine, an operation executes faster on Guaranį than on the corresponding combination without it. This is quite hard to explain, since Guaranį always executes at least as much code as Kaffe does. The tests have been verified so as to ensure that the results are correct, and the generation of the tables from the test results is mostly automated, so there is little place for human error. The better performance can be attributed to factors such as improved fast-RAM cache hit ratio or alignment issues.
The overhead introduced by interception on the interpreter engine is mostly small, because the interpreter is usually orders of magnitude slower than the test for existence of a meta-object. The JIT, however, is severely affected by increased register pressure and additional register spilling and reloading. JIT-compilation costs have increased too, as our tests have shown, but they have only affected the figures of the compile test. In all other cases, we ensure that a method is JIT-compiled before we start timing its execution.
Although the interception code has introduced moderate penalties for invoking static and private methods, the most common kind of invocation (non-final) causes a very small overhead, except on i686, and interface invocations are almost not affected at all.
The bad results for some invocation bytecodes on one x86 platform but not on the other is unexpected, considering that it executes exactly the same machine code on both. It looks like these tests introduce pathological pipeline stalls or branch prediction errors that degrade performance, since the average penalty, measured in compile-diff, is very similar on both x86 platforms, and much lower than most of the individual penalties.
On the other hand, the bad results for all load and store operations on the JIT engines are expected, since these instructions can usually be executed in one or two machine-level instructions, and in Guaranį they require at least one more register and two instructions to test for the presence of a meta-object. Fortunately, in object-oriented applications, field and array operations are usually intertwined with method invocations and object creations. Since the latter operations incur a much smaller penalty, and they are one order of magnitude slower than the former ones, the net performance penalty may be acceptable, as the introduction of reflective capabilities may pay off.
It is worth noting that, although we have introduced the ability to intercept object creation, we have not been able to measure the effect of this addition, due to the impredictability of the garbage collector. Anyway, the overhead is known to be negligible, since a single test was introduced in a rather complex function coded in C.