binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)

[Andrew Haley]

Jeff Sturm writes:
 > On Tue, 9 Sep 2003, Andrew Haley wrote:
 > > 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.
 > 
 > I like this idea...
 > 
 > > 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.
 > 
 > Additionally it'll help avoid the win32 declspec mess.  And by making the
 > static field private, you get a cheaper relocation for PIC code.

Right.

 > For instance fields, you'll want to avoid generating the usual null
 > pointer check that precedes a non-virtual call.  That should be simple,
 > however.  Perhaps check DECL_ARTIFICIAL.

Yes, true.  That's worth a look.

 > > jint *Body::count() __attribute__((pure));
 > > jint *Body::count()
 > > {
 > >     _Jv_InitClass (&class$);
 > >     return &count$;
 > > }
 > 
 > Is this legal for a pure function?  I mean, the _Jv_InitClass call clearly
 > has side effects.

Oops.  Good catch!

 > > [2] "__attribute__((pure))" ensures that the optimizer knows that for
 > > any particular object the address of a field won't change.
 > 
 > Why not __attribute__((const))?  If I understand correctly, pure functions
 > are only subject to CSE and loop optimizations provided global memory
 > isn't modified.

Again, good  point.  I'll experiment with this.

 > > [4] With whole-program optimization and inlining, these access methods
 > > will disappear.  This overcomes any objection that this technique will
 > > be inefficient when statically compiling an executable.
 > 
 > Even without inlining, you're likely trading some dcache pressure for
 > icache, so it might be a wash.

That's true.  We'll see.

Andrew.