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
>> (msec)
>>>>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
>compilation unit)
>
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.
regards
Bryce.