binary compatibility ABI

Wed Sep 10 11:58:00 GMT 2003

On Wednesday, Sep 10, 2003, at 21:22 Pacific/Auckland, Andrew Haley 
wrote:
> Bryce McKinlay writes:
>> Hmm. I presume this would be done for static fields only? Member 
>> fields
>> would still require an offset-table approach because the size of a
>> superclass might change.
>> But I'm trying to make that an *internal* issue, rather than an
> *external* issue. How a class gets the offset of an instance variable
> can be made internal to the implementation of that class.

> So, there need be no ABI issues to do with fields, only methods. That
> means we can totally change the way fields are handled without
> breaking any ABI.

The method (ie otables/address tables) that a piece of client code uses 
to resolve the location of a target field *is* an internal issue, 
between the client code and the runtime - ie it has nothing to do with 
the target code. You could come up with an entirely new technique to do 
this, while retaining backwards compatibility, provided that the 
linker/runtime knows about it. It seems to me that the accessor method 
approach would actually makes things less flexible, because even if we 
switched to a better/more efficient technique later, the accessor 
methods would still have to be generated in order to retain 
compatibility with legacy code.
Even if all field accesses are internally optimized to avoid the method 
call, what you propose would still require an accessor to be generated 
for *every* non-private field. Even without public symbols I suspect 
that would result in a non-trivial increase in binary size. One of my 
goals for the bc-abi is to significantly *reduce* binary size.
> Within a precompiled library such as libgcj, we
> know that a superclass cannot change, and we can take full advantage
> of that.

Of course. But we don't need accessor methods to do that!
Regards,
Bryce.