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

Wed Sep 10 08:50:00 GMT 2003

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.