binary compatibility ABI

Wed Sep 10 12:49:00 GMT 2003

Bryce McKinlay writes:
 > 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.
But what if the target code *is* the runtime? That's the commonest
case.
 > 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.
That is a very good point. And, it seems to me, quite a persuasive
one.
 > 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.
Sure, that's true. But I would expect the extra code to be small,
even in comparison with the size of a symbol. What might not be so
small is the size of the unwinder and debug data for that accessor
method.
Andrew.