binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)

Mon Aug 18 18:56:00 GMT 2003

On 2003年8月15日, Bryce McKinlay wrote:
> >> Unless a and b are in the exact same class as the 'return a + b'
> >> statment, the positions of a and b relative to the class record may
> >> change.
>> Yeah. With full binary compatibility, and assuming 'a' and 'b' are in
> another class, its 5 loads:
>> load offset of a
> load offset of b
> load class pointer
> load a
> load b
>> However the compiler should have a better chance to optimize this than
> it does for PIC loads. eg the class pointer will most likely already be
> loaded, because it is needed for the class initialization check anyway,
> and it should be able to schedule the loads effectively. I doubt it
> will be any slower in most cases than what we have now for PIC. It
> might even be faster due to better scheduling & locality.

Right. Given one GOT per DSO, it tends to be large and sparsely accessed,
and probably exhibits poor locality (though I have no direct evidence).
(I'm assuming the offset tables aren't public, so no GOT access is
necessary to get the table address.)
> If a and b are in the same class, we can always skip the loading of
> offsets as they are known at compile time, assuming the size of
> non-user fields in the class object is fixed by the ABI. If a and b are
> in another class but the same binary, we can skip the offsets only if
> we do not allow runtime class replacement. Thats probably a reasonable
> thing to do by default for user code, but perhaps not for libgcj.

Egads. To allow runtime class replacement everywhere you'd have to
disable useful optimizations such as cross-module inlining.
My impression is that libgcj is vital to overall application performance.
I doubt users can replace code in java.lang.* without breaking things.
Perhaps libgcj should distinguish bootclasspath code from the rest, and
not allow runtime class replacment in the former?
Jeff