We Keep Coding

Post callback for JVM out of memory

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.

Is there any way we can execute some java code when a jvm process is killed?

We want to execute some java code or shell code before a JVM exits when it is killed manually. Our application is not running in a container. We need to monitor it automatically using the Java code itself or some command line tool.

You can add a shutdown hook by using Runtime.getRuntime().addShutdownHook(). Such a shutdown hook is run by the JVM, once the JVM' process terminates. However, note that this is not always the case. A JVM might get killed before it gets the chance to trigger its shutdown hooks. This is mentioned in the javadoc:
In rare circumstances the virtual machine may abort, that is, stop
running without shutting down cleanly. This occurs when the virtual
machine is terminated externally, for example with the SIGKILL signal
on Unix or the TerminateProcess call on Microsoft Windows. The virtual
machine may also abort if a native method goes awry by, for example,
corrupting internal data structures or attempting to access
nonexistent memory. If the virtual machine aborts then no guarantee
can be made about whether or not any shutdown hooks will be run.
You can use a shut down hook as follows:
Runtime.getRuntime().addShutdownHook(
new Thread("app-shutdown-hook") {
#Override
public void run() {
System.out.println("bye");
}
});
You can and should also deregister a shut down hook once it is no longer required. Otherwise, the JVM can never garbage collect the hook.

Not sure what you mean by "killed"?
If it is by a signal, it depends on the signal. For some of these you can add a JVM shutdown hook which the JVM will execute... But not all. SIGKILL is instant death for instance.
With shell code you can do that:
my java command;
# inspect $?
Run that as a background process; you can tell whether the JVM was killed by inspection of $? since it will be 128 or greater (127 + number of signal used to kill).
Note that you can BOTH capture the command output if needed AND inspect $?:
output=$(my java command);
# inspect $? -- ONLY THEN inspect $output
Of course, add quotes where appropriate etc etc.
And of course you can also store the value of $? before inspecting it later:
my command;
RC=$?;
# do something else
# inspect $RC
Finally, it is important to note that in custom code which uses System.exit() you should avoid exiting with 1: the JVM will exit with that return code whenever main() throws anything.

Please see this post. You just have to tell the runtime you want to execute it at the end of everything. Tada.

How does "kill -QUIT process_id" work?

I'm just curious. The man page for kill says that QUIT, aka signal # 3, is a "core" signal. It seems that all it does, for Java processes, is dump the thread information. So, is the QUIT as misnomer? Is it just that the JVM implements a singal 3 handler that dumps threads?

QUIT is arguably a misnomer for Java. But by that argument any signal name could be a misnomer if an application is allowed to change the default behaviour of the signal's handler.
In reality, the correspondence between UNIX signal names and what they actually do has always been a bit vague and tenuous. However, developers have been dealing with this "issue" for 30+ years without it being a real problem.
And yes, the Java thread stack dump behaviour is implemented by the JVM. The default UNIX / LINUX behaviour is to create a memory dump of the process, unless this is inhibited by other factors.

Yea, the JVM captures the #3 signal to dump threads. By default, for a normal unix process, it dumps core (i.e. take a memory snapshot of the process and write it to a file) and exits.
For Java, that isn't very helpful, so it does a thread dump instead.

Is it possible to handle a SEGFAULT orginating in native code?

I have a Java 1.6 application that accesses a third party native module, through a JNI class provided as the interface. Recently we noticed that a SEGFAULT is occurring in the native module, and is causing our application to crash. Is it possible to catch and handle this event, at least to log it properly before dieing?
I tried both Java techniques in the article from kjp's answer. Neither worked. Attempting to install a signal handler on 'SEGV' results in the exception
Signal already used by VM: SEGV
The shutdown handler I installed simply failed to fire, presumably because of what the IBM article states:
Shutdown hooks will not be run if
Runtime.halt() method is called to terminate the JVM. Runtime.halt() is provided to allow a quick shutdown of the JVM.
The -Xrs JVM option is specified.
The JVM exits abnormally, such as an exception condition or forced abort generated by the JVM software.

If all you want to do is log and notify you can write a script which runs your application. When the application dies, the script can detect whether the application terminated normally and from the hs_errXXXX file which has all the crash/SEGV information and mail it to someone (and restart the application if you want)
What you need to do is to run the faulty JNI code in another JVM and communicate with that JVM using RMI or JMS or Sockets. This way when the library dies, it won't bring down your main application and you can restart it.

Based on several weeks of research at the time, as well as conversations with JVM engineers at a conference this is not possible. The system will not let you install a SignalHandler on the SEGV signal.

How JVM use operating system when creation of thread?

Here i try to learn java thread clearlly.. On which process JVM create the thread.
Suppose if i create a thread in java then how JVM create this thread? To whom it will send to exicute?.. Which one is the base process for this...

Most JVMs use standard OS calls to create native threads (eg, the Win32 CreateThread API, or POSIX pthread_create), and pass a native function within the JVM which proceeds to execute the Java code in the thread.

There is a separate JVM process for every running Java application. The threads that the application creates are created within that process.

Actually the Java Virtual Machine Specification does not specify how threads are to be handled by a JVM. There is only a high level description. The Sun JVM itself made a change in this regard: Up to Java 1.1 it used so called Green Threads that are managed by the JVM itself. Later it used native threads that the host operating system provides.