I call a dll from Java using JNI. The DLL calls another thirdparty library which spawns a bunch of threads and sends callbacks to my dll. I want these callbacks to be attached to the JVM. What is the best way to do this? I think since the threads call the callback method, the callbacks aren't attached to the JVM, so I have to attach it?
Is there no... inheritance, like all threads created by this thread will automatically attached to the JVM?
I've looked at the documentation but I can't find it.
Thanks
You have to manually call AttachCurrentThread() (and DetachCurrentThread()) from each thread that needs to call into the VM. There is no automatic mechanism.
Related
In our java application, we need to send email in case the application goes out of memory and recovers from it by its own. To do so, we need a callback kind of thing that should be called once the JVM recovered from OOM. Is there such a callback in Java?
Use -XX:OnOutOfMemoryError=<command> JVM option.
If you need more flexible error handling within the Java process itself, look at ResourceExhausted JVMTI callback.
I'm working with Java Agent (creating a profiler) using code instrumentation (using Javassist for Instrumentation). I need to run few functions in my Java Agent profiler after the complete execution of java program. Something after the main function, like post-main (like we have premain). Is that possible?
There is no such thing as a postmain method and its semantics would not be clear either. Many programs run until they are killed. This requires the application to terminate and not to run different code.
Java offers shutdown hooks via the Runtime class that are triggered on an application's termination but which must not perform long-lasting operations. Also, they are not executed if a program is killed.
For a profiler, you would need to process data regularly and you could attempt to flush your buffers on termination without a guarantee.
I have an Android Native Game which is running through JNI.
When I wanted to quit the application, I am calling the Activity's Finish method. The activity is getting destroyed, but the native ( process or memory ) is not getting destroyed ( or cleared ).
So when I launch the game again, the previous state of the game is restored directly with out any native loading.
How can kill my native process as well, to free the resources.
Android's Activity Lifecycle is heavily decoupled from the concept of a process, which does make things tricky when you port a conventional program architecture to it.
Ideally, you would modify your native program to resemble the Activity Lifecycle by having initialization and destruction routines, such that you can tell it to stop and clean up. Any threads should cease running. Try to clean things up to the point where calling the initialization routine again will result in a clean, functional new instance.
More desperately, you could try to finish() your activity and then call System.exit(). This is highly discouraged - it will leave problematic-looking messages in logcat, and it's possible Android may even quickly re-create you in a new process, in which case you'll want to have logic to avoid restarting the native engine, too.
Another thing to look at could be running your native code in a distinct process, either hosted in an android component declared that way in the manifest, or actually as a stand-alone executable running in its own purely native process (no dvm or art) that you communicate with using pipes, unix sockets or possibly shared memory.
Android Native process will not stop even activity is finished..
two methods i know to overcome this issue are
1) Create a method in your jni native class for stop the native process and call it form your activity.
2)just call android.os.Process.killProcess(android.os.Process.myPid());
2nd method is not recommended use only if no way else..
One thing you should know is finish() or System.exit() only can destroy current activity. If you want to quit the application, you should clear the activity stack first.
This link seems to suggest that "it just works": (pretty far on the bottom under 7.3 Attaching Native Threads) http://java.sun.com/docs/books/jni/html/invoke.html
I don't see how that is possible, is the embedded JVM going to start its own threads automatically? Or queue the JNI calls? How else could there be multiple calls to the same virtual machine. which I haven't instructed to do any threading?
Any way I can imagine that to work is, if the java code will simply be executed in the same calling thread as the c code. Is that correct? That would mean that I don't have to do any threading in Java.
The jvm does not have to create its own threads, the method calls are executed on the native threads that make them. The AttachCurrentThread and DetachCurrentThread will take care of any necessary jvm internal state management, for example creating java Thread objects wrapping the native threads.
The JVM starts its own threads which it needs to run. You trigger this thread creation by starting the JVM.
I have some native thread that needs to call into Java. For that, I need to attach the thread to the VM using AttachCurrentThread. Since this callback will happen quite often, the thread should probably stay attached. Calling AttachCurrentThread multiple times is fine ("Trying to attach a thread that is already attached is a no-op.")
Do I have to call DetachCurrentThread before the thread exits, will it happen automatically, or is it not even required? What happens if I must call detach, but don't? Would it just "leak," or could this even corrupt the VM state?
I have checked the Java Native Interface specification, but either missed this, or it really is unspecified.
My question applies specifically to Sun JDK 6 on Windows XP.
I think that the confirmation that you want is here: http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/invocation.html#wp1060
A native thread attached to the VM must call DetachCurrentThread() to detach itself before exiting.
And in the next section, there's the rationale:
The VM waits until the current thread is the only non-daemon user thread before it actually unloads. User threads include both Java threads and attached native threads.