Question

I am writing the C++/Native side of a text/VoIP program that utilizes JNI. Currently there are three functions on the C++ side that will likely be called by the Java code regularly. The frequency at which the functions are called will depend on how often the user sends/receives text messages and how active their friends are in changing their presence/status. Each of the three functions follow the pseudo code below and I am not sure if it would be wise (or even possible) to “globalize” anything within the functions.

JNIEnv *env;
if (jvm_->GetEnv((void**) &env, JNI_VERSION_1_6) < 0)
{
[print error and return]
}

jclass stringclass = env->FindClass("java/lang/String"); // Same for all 3
jstring passinfo = env->NewStringUTF([str-info-to-pass]); // Different for all 3
jclass cls = env->FindClass([directory to calling Java function class]); // Same for all 3
[check if cls found, print error if not found and return]

jmethodID methID = env->GetStatisMethodID([arguments for the function]); // Different for all 3
[check if methID found, print error if not found and return]

jobjectArray args = env->NewObjectArray([arguments to build argument structure being passed to function]);
[call Java function, passing right arguments]

I was thinking that I should/would be able to move the jclass stringclass, jclass cls and JNIEnv *env out of the functions and make them globals that were set during the JNI_OnLoad function call. Is this possible/advisable? Will these values be somehow different from the OnLoad function to these functions? Should I just instantiate them as globals and still set them each time in the function call? And, will doing any of these really increase performance in any noticeable amount?

Answer 1

Possible, yes. Wise, it depends. Define for yourself what is a “noticeable amount”. What cadence of JNI calls you expect? I think you could see some measurable impact of caching starting at 10+ calls per second. Is that a case? Anyway, in my personal experience, nicely done caching cleans up the code, makes it shorter and more readable. So i will give some advice anyway.

Caching results of FindClass, yes absolutely. Generally anything reusable and “static”, what you are looking up by a symbolic name – which introduces a penalty of symbolic lookup, contrary to simply using an already cached pointer. Liang JNI book talks also about field and method ids, so your GetStaticMethodID applies. jmethodID is simpler in the sense that the result of Get(Static)MethodID can be directly cached: it is valid for any further calls. Unlike FindClass which returns a local reference, so for valid caching (and to make jmethodID really persistent) you must create NewGlobalRef from it – and delete it when appropriate. A nice comprehensive example is found in the JNI_OnLoad tutorial. On the other hand, there is no point in caching JNIEnv, you get it again with every JNI call. Cached JNIEnv would be also invalid if you happen to call the JNI methods from another thread than the one from which you cached.