Re: CNI changes (Was: Binary Compatibility)

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > PR4066> "The stubs generated by `gcj -fjni' are not thread-safe.
 > PR4066> I believe the code they generate to cache the JNI method
 > PR4066> pointer can fail in some rare situations.
 > PR4066> (This code relies on double-checked locking, which is
 > PR4066> known to be bad.)"
 > 
 > 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.

Oh, I see.  Well, this may not always be atomic on every platform, but
IMO it's very unlikely to be a problem.  But even if it isn't atomic,
you would have to have fairly bizarre memory semantics to end up with a
corrupted pointer.

Besides, I have some vague memory that Java semantics actually require
storing into an int field to be atomic.  [Looks it up.]  Oh yes,
according to Section 8.3 of the VMspec that seems to be the case.  But
a method pointer might on some machines be a long rather than an int,
so synchronization may be required.  I get it now, I think.

Andrew.