about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)
Mon Jan 28 16:25:00 GMT 2002
Tuomas Leikola wrote:
>>I measured the time taken to invoke a method 10,000,000
>>times for GCJ. Java source files attached to this mail
>>are compiled with -O option and executed on a 600 MHz
>>Pentium III PC.
>> invokevirtual: 234 (faster than invokestatic)
>> invokespecial: 68
>> invokeinterface: 554
>> invokestatic: 319
>the same object or different objects? if they cause l2 cache misses? then
>again, the object will most probably need to be accessed anyway.
Repeated virtual invocations on the same object can be optimized fairly
well by the compiler. Thats because it can cache the method pointer and
reuse it for each call. I agree that, outside of loops, locality is
poorer for vtables.
>how can invokestatic be slower? didn't it get inlined or what? (iirc,
>private, static and final can be inlined if they are in the same library or
In this case it didn't get inlined. GCJ's current inliner is pretty
stupid and doesn't work a lot of the time when it should. I don't think
it ever inlines static methods ;-(
In theory a static call with PIC requires just about as much work as a
virtual call - it still needs to look up the code pointer in some table
that is filled out by the linker. However the real reason static is so
much slower here is due to GCJ adding a class initialization check to
the start of every static method. I think we can do better by putting
this check at the call site rather than in the method.
More information about the Java