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

Wed Sep 10 04:41:00 GMT 2003

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.
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.
> 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.
> [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.
> [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.
Jeff