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.
Related
How do I distinguish running Java threads and native threads?
In Linux there will be Parent process for every child process, and they say 0 is the parent of all the process, will there be a Parent thread of all the forked Java threads?
How do I know which Java thread is related to OS thread (if a Java thread forkes a native process thread).
Is there any naming convention of Java threads and OS threads?
Can a running Java threads can be suspended or killed from another Java code?
On Linux, Java threads are implemented with native threads, so a Java program using threads is no different from a native program using threads. A "Java thread" is just a thread belonging to a JVM process.
On a modern Linux system (one using NPTL), all threads belonging to a process have the same process ID and parent process ID, but different thread IDs. You can see these IDs by running ps -eLf. The PID column is the process ID, the PPID column is the parent process ID, and the LWP column is the thread (LightWeight Process) ID. The "main" thread has a thread ID that's the same as the process ID, and additional threads will have different thread ID values.
Older Linux systems may use the "linuxthreads" threading implementation, which is not fully POSIX-compliant, instead of NPTL. On a linuxthreads system, threads have different process IDs.
You can check whether your system is using NPTL or linuxthreads by running the system's C library (libc) as a standalone program and looking under "Available extensions" in its output. It should mention either "Native POSIX Threads Library" or linuxthreads. The path to the C library varies from system to system: it may be /lib/libc.so.6, /lib64/libc.so.6 (on 64-bit RedHat-based systems), or something like /lib/x86_64-linux-gnu/libc.so.6 (on modern Debian-based systems such as Ubuntu).
At the OS level, theads don't have names; those exist only within the JVM.
The pthread_kill() C function can be used to send a signal to a specific thread, which you could use to try to kill that specific thread from outside the JVM, but I don't know how the JVM would respond to it. It might just kill the whole JVM.
There is no standard; this completely depends on the Java implementation which you're using. Also, don't mix up "native threads" and "native processes". A process is an isolated entity which can't see into the address space of other processes. A thread is something which runs in the address space of a native process and which can see into the memory of other threads of the same process.
What you see on Linux is something else: Some versions of Linux create an entry in the process table for each thread of a parent process. These "processes" aren't real processes (in the isolation sense). They are threads which can be listed with the ps command. You can find the process which created them by using the parent PID (PPID).
There is no generic solution how Java threads are mapped to OS threads, if at all. Every JVM implementation can do it in a different way.
There is also a pure Java thread implementation, called green threads. This is used as a fallback if native threads aren't supported or the system isn't multithreaded at all. You won't see any green threads at your OS.
Can a running Java threads can be suspended or killed from another Java code ?
If they are running at the same JVM, yes, with stop(). But that's not a good solution and may work, or not. interrupt() allows the thread so safely shut itself down.
There is no way to kill threads outside of the JVM I know of. If a OS really supports killing of threads, I wouldn't expect the Java application to run correctly afterwards!
Can a running Java threads can be
suspended or killed from another Java
code ?
In theory yes. In practice, the Thread.kill() and Thread.suspend() methods are deprecated because they are unsafe except in very limited situations. The basic problem is that killing or suspending a Java thread is likely to mess up other threads that depend on it, and shared data structures that it might have been in the middle of updating.
If "another Java code" is meant to mean another JVM, then the chances of it working are even less. Even if you figured out how to send the relevant thread signal, the results are completely unpredictable. My bet is that the "target" JVM would crash.
I have some search threads which are storing results on them. I know when thread starts JVM native code proxies the request to create new native thread on the OS. This requires some memory outside of the JVM. What happens when the thread dies and I keep reference to it and use it as POJO. Does it still exist somewhere as native thread to OS (and use memory outside jvm) ?
No. An OS thread is actually created and started when Thread.start() is called, and it stops existing when the thread stops running. Whether the Java object of type Thread, used to start the thread, is garbage-collected or not doesn't change anything.
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.
is there a way to determing if a jvm is shutting down normally? Shutdown hook can only spawn a thread, is there a way to determine if the JVM is existing normally or abnormally at that time?
You could write a file on startup and delete it again on graceful exit. If the JVM is gone but the file is still there you know that it crashed or has otherwise exited in a unintended manner.
I remembered a similar question being asked time ago. One possible course of action is the use of SignalHandler.
You can read the full article here. It appears to be related to IBM JVM but I think it is equally valid for Java Hotspot.
A little-known feature of Java is the
ability of an application to install
its own signal handler, which is
supported through the sun.misc.Signal
class. However, use caution when using
classes from the sun.misc package
because it contains undocumented
support classes that may change
between releases of Java. You can
install a Java handler for any signal
that is not used by the JVM. These
signal handlers are similar to native
handlers because they're invoked when
a native system signal is raised, but
they will always run as a separate
Java thread. Essentially, when a
signal is raised for which a Java
signal handler is available, the JVM's
"signal dispatcher thread" is woken up
and informed of the signal. The signal
dispatcher thread then invokes a Java
method to create and start a new
thread for the installed Java signal
handler. To write a Java signal
handler, define a class that
implements the sun.misc.SignalHandler
interface and register the handler by
using the sun.misc.Signal.handle()
method.
Check return sttaus using command $?
When the JVM is shutting down normally, this means that the main thread has ended. If the JVM is shutting down for some other resaon (e.g. the user pressed Strg+C), the main thread is still running. So you can store a reference to the main thread in your shutdown hook and check whether this thread is still alive. Of course this assumes that the main thread will normally be the last running thread in your application. I don't know how the situation is if one of the threads called System.exit(), but you could easily find this out.
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.