CNI changes (Was: Binary Compatibility)

Mon Aug 4 15:38:00 GMT 2003

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.