Re: binary compatibility ABI

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Wednesday, Sep 10, 2003, at 03:14 Pacific/Auckland, Andrew Haley 
wrote:

> I've been giving this some thought.
>
> It seems to me that the right way to handle access to fields is
> automatically to generate access methods for them.  Unlike the
> traditional Java access methods getFoo() and putFoo(), these methods
> will return the address [Footnote 1] of a field rather than access the
> contents of a field.

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.

I'm not sure what advantage this would have over an address-table (ie 
same as offset-tables but with actual addresses instead of offsets) 
approach - seems to me that using accessor methods would be less 
efficient in both space and time, and is also more complicated since, 
as you mention, calls to the accessor methods themselves would still 
have to be indirect-dispatch calls in order to be binary-compatibility 
compliant, otherwise we'd get link errors if a static field or its 
class disappears.

> The symbol that is the name of a static field will no longer need to
> be exported; all CNI code will use the access methods to get at static
> fields.  That way we will get full binary compatibility for CNI code,
> and we don't have to touch the C++ compiler.

Except that the C++ compiler would still need to be changed in order to 
implement indirect-dispatch calls, wouldn't it? Once we've done that - 
ie got the C++ compiler generating otables and having them registered 
with the runtime, I'd say we're 90% of way to getting fields done as 
well.

> Also, we can dispense with the call to initialize the class that
> contains a static data member:

I think that keeping the initialization check/call at the call (or 
field access) site gives us more opportunity to optimize it out at 
compile time. eg: hoisting it out of loops, eliminating it if class is 
already known to be initialized in the current method, keeping a local 
cache, etc.

Regards

Bryce.