[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

JavaHL unneccessary JNI method calls?

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-04-19 00:15:43 CEST

Do we need all the calls to DeleteLocalRef in the C++ JavaHL code after
a method has completed and for it to clean up after itself. We have a
ton of this kind of code:

   env->CallVoidMethod(m_callback,
                       sm_mid,
                       jChangedPaths,
                       (jlong)rev,
                       jauthor,
                       (jlong)commit_time,
                       jmessage);
   if (JNIUtil::isJavaExceptionThrown())
     return SVN_NO_ERROR;

   env->DeleteLocalRef(jauthor);
   if (JNIUtil::isJavaExceptionThrown())
     return SVN_NO_ERROR;

   env->DeleteLocalRef(jmessage);
   // No need to check for an exception here, because we return anyway.

   return SVN_NO_ERROR;

Why can't we just return after calling env->CallVoidMethod?

I'm not saying we get rid of this call everywhere, such as utility
functions that set up Java objects, but for calls that return directly
to the JVM.

Reading this:

http://java.sun.com/docs/books/jni/html/refs.html

The JVM cleans up local references already when the JNI call completes.
  So wouldn't it be faster for the JVM to do this then for us to have to
call through env->DeleteLocalRef all the time? Then we also have to
check for exceptions, which doesn't seem particular light to me either:

bool JNIUtil::isJavaExceptionThrown()
{
   JNIEnv *env = getEnv();
   if (env->ExceptionCheck())
     {
       // Retrieving the exception removes it so we rethrow it here.
       jthrowable exp = env->ExceptionOccurred();
       env->ExceptionDescribe();
       env->Throw(exp);
       env->DeleteLocalRef(exp);
       setExceptionThrown();
       return true;
     }
   return false;
}

 From this page:

http://java.sun.com/docs/books/jni/html/fldmeth.html

"The overhead of field access using the JNI lies in the cost of calling
through the JNIEnv. Rather than directly dereferencing objects, the
native code has to perform a C function call which in turn dereferences
the object. The function call is necessary because it isolates the
native code from the internal object representation maintained by the
virtual machine implementation. The JNI field access overhead is
typically negligible because a function call takes only a few cycles."

Also, what about adding a new

bool JNIUtil::isJavaExceptionThrown(JNIEnv *env);

function that takes the JNIEnv from the caller, which presumably already
has one? How expensive is the getEnv() call?

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 19 00:15:58 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.