binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)
Thu Aug 14 22:40:00 GMT 2003
On Friday, Aug 15, 2003, at 05:21 Pacific/Auckland, Jeff Sturm wrote:
> On Thu, 14 Aug 2003, Andrew Haley wrote:
>>> static int a, b;
>>> return a + b;
>>> Does this require 2, 3 or 4 memory loads?
>>> (I believe 2 is the answer for non-PIC, 4 for PIC. If we take
>>> of the fact that static fields are at a fixed offset from the class
>>> record, it can be done in three, while preserving position
>> 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
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
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.
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.
Non-static field loads are much the same, in that offsets are known at
compile time for fields in the same class and maybe the same
compilation unit. The catch is that in classes that don't extend
directly from Object, we don't know the size of our superclasses - in
this case there would be just one offset to load for all fields in the
class, which is added to the object pointer to get the base offset. For
classes that extend directly from Object (or, perhaps, have
superclasses that are all in the same binary unit) we can skip that too.
More information about the Java