CNI changes (Was: Binary Compatibility)

[Boehm, Hans]

I'm not sure there's anything very special about IA64 here.  A function pointer consists of one word, which points to a struct containing both the GOT pointer and the instruction address.  (I have a vague recollection that at least AIX on Power does something similar.  I doubt this part is unique.)  Function pointer assignments are still atomic.

IA64 may be unique in that vtables contain these structs directly instead of the pointers to them.  But I think that's not relevant here.

As Jeff points out, the real question is probably whether all the relevant state is guaranteed to be in place if cached_function is not NULL.  If _Jv_LookupJNIMethod sets up some state necessary for the call to complete, then this is probably wrong, since that state may not be visible by the time the call is made.  On IA64, this could be fixed by treating cached_function as a C volatile.  On X86, it's generally assumed to be OK as is, assuming you go along with everyone else, and don't take the official spec too seriously.

Hans

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Monday, August 04, 2003 8:54 AM
> To: Tom Tromey
> Cc: Andrew Haley; Anthony Green; java@gcc.gnu.org
> Subject: Re: CNI changes (Was: Binary Compatibility)
> 
> 
> On 4 Aug 2003, Tom Tromey wrote:
> > Andrew> What is wrong with the current scheme?
> >
> > We generate JNI stubs that look like:
> >
> >     if (cached_function == NULL)
> >       cached_function = _Jv_LookupJNIMethod(...)
> >     (*cached_function) (...);
> >
> > I'm not sure that assignment is always atomic, which is why 
> I sent in
> > the PR.  (If it is always atomic we can just close this.)
> 
> I don't know of any target that wouldn't do an atomic store of
> cached_function.  The usual problem with this double-checking 
> idiom isn't
> the assignment itself however but ordering of memory writes before and
> after the assignment (i.e. side effects).
> 
> If _Jv_LookupJNIMethod has no important side effects here, my hunch is
> that the PR should be closed.  (Come to think of it... I wonder about
> IA-64.  I vaguely recall that a "function pointer" is really 
> a gp/entry
> pair on IA-64.  That one may not be atomic after all, or I may be
> confused.)
> 
> Jeff
>