This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CNI changes (Was: Binary Compatibility)


>>>>> "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.  (If it is always atomic we can just close this.)


It would be safer to call:

    _Jv_LookupJNIMethod(..., &cached_function)

and have _Jv_LookupJNIMethod do locking internally.


This change isn't a big deal.  It could easily go in 3.4.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]