about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)
Wed Jan 30 22:31:00 GMT 2002
>>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 could confirm it by disassembling the generated code.
You can use "gcj -S ..." to get the assembly code. No need to disassemble!
>>I think we can do better by putting
>>this check at the call site rather than in the method.
>I doubt whether moving the check to the call site can
>reduce the number of runtime checks. If GCJ can hoist
>the check code out of a loop or a hot-spot, the number
>of the checks can be reduced. But I guess such hoisting
>is hard to do because of Java's strict nature.
It is safe to hoist provided that there are no side-effects between the
start of the loop and the static call (or field access). But, you are
right - this does likely rule out many loops.
Call-site initialization does allow us to eliminate the checks for any
method which is in the same class or any super class of the call site,
however. Also, if any field access, static call, or local field of the
target class appears in the call-site method, we know that class (and
its superclasses) must be initialized and thus can remove the check.
>Some JIT compilers do code patching to suppress the
>second and later invocation of a class initilizer check.
>How do you think about it?
Code patching is not a good option because it very platform specific,
and would force copy-on-write of the shared library memory. Andrew's
idea of having two entry points is good if GCC can be made to support
it. I don't like the idea of patching the PLT - too hairy and
platform-specific. Better to construct our own static method tables
(which would have other benefits too).
More information about the Java