This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: CNI changes (Was: Binary Compatibility)
- From: Tom Tromey <tromey at redhat dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'Jeff Sturm'" <jsturm at one-point dot com>, Andrew Haley <aph at redhat dot com>, Anthony Green <green at redhat dot com>, java at gcc dot gnu dot org
- Date: 04 Aug 2003 12:38:53 -0600
- Subject: Re: CNI changes (Was: Binary Compatibility)
- References: <75A9FEBA25015040A761C1F74975667D01442280@hplex4.hpl.hp.com>
- Reply-to: tromey at redhat dot com
>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
Hans> As Jeff points out, the real question is probably whether all
Hans> the relevant state is guaranteed to be in place if
Hans> cached_function is not NULL. If _Jv_LookupJNIMethod sets up
Hans> some state necessary for the call to complete, then this is
Hans> probably wrong, since that state may not be visible by the time
Hans> the call is made.
All _Jv_LookupJNIMethod really does is look up the method. It
shouldn't be modifying any state that matters.
So I guess that implies that the current function is ok, and we can
just close the PR. Cool.
Hans> On IA64, this could be fixed by treating cached_function as a C
Hans> volatile.
But just to be clear, you're saying that we only need cached_function
to be volatile if _Jv_LookupJNIMethod does something other than return
the function pointer.
Tom