Re: JavaHL unneccessary JNI method calls?

Hi Blair,
the reason for all this calls is that the number of local references is
limited to about 30 or 60. If you do not release them in cases where you
do not return directly to the JVM, you will see exceptions.
That is why I always deleted all local reference, as soon as possible.
Regards,
Patrick

Blair Zajac wrote:
> 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
>

-- 
Qint Software GmbH
Fichtenstr. 19
82110 Germering
+49 89 89026748
Sitz: München HRB 117326
Geschäftsführer: Hans Marggraff, Patrick Mayweg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org