What are the consequences if we try to attach a Native Thread permanently to the DVM (JVM)?

Is it feasible to attach a native thread permanently to the JVM (AttachCurrentThread) (or) is it better to attach when ever required (calling java functions) and detach immediately once the work is done

I wrote a sample native app with the above cases, didn’t find any difference. But by googling, vaguely I came to know that, when attached to JVM , JVMs thread scheduling is responsible for scheduling else OS will schedule the native thread (if not attached). Is this true?

  • Couldn't expand RemoteViews
  • Android - Custom rating bar looks like its bleeding
  • AlarmManager, BroadcastReceiver and Service not working
  • How to add multiple views to window manager in Android
  • 23.2.0 set vector drawable as background in 4.X
  • difference between MICRO_KIND and MINI_KIND in mediastore in android?
  • It is important to detach any thread that has been previously attached; otherwise, the program will not exit when you call DestroyJavaVM. – http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniref.html#attach

    Will there by any performance issues?
    Please let me know if anyone knows, its one my important design aspect.

    Thanks & Regards.

    Related posts:

    android View not attached to window manager
    Problems found loading Plugins in Android Studio
    How to run a service every day at noon, and on every boot
    Play RTSP streaming in an Android application
    What special powers does ashmem have?
    Android - unable to uninstall application
  • java.lang.UnsupportedOperationException: This is not supported, use MenuItemCompat.setOnActionExpandListener()
  • Android Retrofit2 Refresh Oauth 2 Token
  • Android x86 virtualbox + camera
  • Is it possible to make ActionBar tabs height higher than ActionBar height? If so, how?
  • Android Test Driven Development
  • NullPointerException: Attempt to invoke virtual method 'int java.util.ArrayList.size()' on a null object reference
  • 3 Solutions collect form web for “What are the consequences if we try to attach a Native Thread permanently to the DVM (JVM)?”

    Generally speaking, the main performance cost is the thread creation at OS level. Either the thread is creating natively and then attached or directly created as java.lang.Thread from Java API.

    If you re-use the same native thread, performance will be good. By the way, do not create dozens of native threads.

    The JVM does not schedule threads itself. It may force them in sleep state for various reason like garbage collection. In that specific case, it has to wait for a JNI call from a native thread before collecting. So you have to avoid too long code execution without JNI call to keep the VM heap consumption low.

    Moreover, you have to take care to call DeleteLocalRef before detaching a native thread or else your VM will leak memory.

    When a native thread is attached permanently, not able to exit the native thread. Its crashing when we try exiting the native thread without detaching. But when we detached, native thread was able to do graceful exit.

    I haven’t experienced any consequences except for boosted performance.

    That is exactly what I do in an application that is shuffling directly-allocated ByteBuffer data between the two layers. I discovered the cost of constantly attaching/detaching was very high, as one might expect. My approach is to launch a single Java-managed thread that makes a blocking JNI call at launch, which in the C/C++ layer contains a condition/signal-style loop (so as to not eat CPU cycles). I can then signal down to the loop anytime data is ready for processing, and conversely I can signal up to Java when the hard work is done.

    new Thread(() -> myBlockingJNICall()).start();

    Then down in the C layer:

    #ifdef __cplusplus
    extern "C"
    #endif // __cplusplus
        static JavaVM *jvm = nullptr; // captures the JVM on load
        JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *the_jvm, void* /*reserved*/)
            jvm = the_jvm;
            return JNI_VERSION_1_2; // must export 1_2 to use any of the new functions, 1_1 otherwise
        JNIEXPORT jboolean JNICALL Java_myBlockingJNICall(JNIEnv *env, jobject)
           // loop forever waiting for work and using env for signalling
           // jvm is stored in case we need to manually attach (or perform more complex work requiring jvm access)
           return JNI_TRUE;
    #ifdef __cplusplus
    #endif // __cplusplus
    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.