Re: binary compatibility ABI

[Andrew Haley <aph at redhat dot com>]

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.