HP-UX Java™ - Using Signals

Unless specified otherwise, the information in this chapter applies to both HP-UX PA-RISC and
HP-UX Itanium® Processor Family systems.

HP-UX defines several signal interfaces that allow a process to specify the action taken upon receipt of a signal. The man pages sigaction(2), signal(2), sigvector(2), bsdproc(2), and sigset(2V) describe the various HP-UX signal interfaces. The man page signal(5) describes the HP-UX signals.

There are two HP-UX signal types, asynchronous and synchronous. Asynchronous signals are not usually attributable to execution of code; synchronous signals are usually attributable to execution of code.

Asynchronous signals include the keyboard-generated signals such as SIGINT and SIGQUIT, and the sent-to-process signals such as SIGHUP. Synchronous signals include hardware generated signals such as SIGSEGV, SIGBUS, and SIGFPE and the sent-to-process signals such as SIGPIPE and SIGSYS.

The information below describes the HP-UX signals handled by the Java™ virtual machine (JVM) and describes the effect once the JVM receives the signal.

Signals used internally by the JVM should not be generated by native methods, their handlers must not be overridden, and they should not be blocked for extended periods. In particular, none of these signals should be blocked when making a call from a native method back into the JVM.

In addition, the SIGABRT signal handler can be overridden, but the handler should, for correct semantic program execution, cause the termination of the JVM. SIGBUS is reserved for future internal use by the JVM and native methods should not attempt to install handlers for it.

Signal handlers for all of the other signals listed here may be overridden by native methods and used freely. Signals not listed here may be freely used by native methods.

SIGHUP, SIGINT, and SIGTERM are asynchronous signals that cause a silent termination of the JVM.

The JVM installs signal handlers for SIGHUP, SIGINT, and SIGTERM, and if these are overridden, the shutdown hooks will not be executed. Note that for any of these signals a handler is not installed if the signal handlers' disposition is set to SIG_IGN. For instance, this could be as a result of starting the application using nohup(1).

SIGABRT, SIGBUS, SIGILL, SIGIOT, SIGEMT, SIGSEGV, SIGSYS, SIGTRAP (synchronous signals) and SIGXCPU and SIGXFSZ (asynchronous signals) cause termination of the JVM. If the -Xnocatch option is used, the termination is silent and a core file is produced. If the -Xnocatch option is not used, a dump of all of the Java™ stacks is written to stderr, the JVM terminates with a SIGABRT and produces a core file.

SIGQUIT is an asynchronous signal that is intercepted by the JVM. It causes the JVM to print the Java™ call stack for each active Java™ thread in the process to standard error. All locks held are printed below the name of the method in which the lock was acquired. Similarly, a lock trying to be acquired is printed. The JVM resumes execution after all information has been written.

SIGFPE is a synchronous signal used by the JVM and the HotSpot JVM to implement its runtime.

The following options to the HotSpot JVM control the signals used by the JVM and installation of other signal handlers. The Classic JVM does not accept -XX options. Note that -XX options are non-standard options and are subject to change in future releases.

-XX:+AllowUserSignalHandlers
Instructs the HotSpot JVM not to complain if the native code libraries install signal handlers. This only matters if the handlers were installed when the VM is booting.

-Xusealtsigs (Replaces the -XX:+UseSIGUSR2 option beginning with SDK 1.4.1.00, 1.4.2.00, and 1.3.1.13)
Replaces the -XX:+UseSIGUSR2 option. Instructs the JVM to avoid using SIGUSR1 and SIGUSR2 for internal operations (like Thread.interrupt() calls). In SDK 1.4.1 and later, by default the JVM uses both SIGUSR1 and SIGUSR2. (In SDK 1.3.1.13 only SIGUSR1 is used.) If -Xusealtsigs is used, then two signals halfway between SIGRTMIN and SIGRTMAX will be chosen instead. This allows you to implement third party middleware applications better that may want to use SIGUSR1 or SIGUSR2 for other purposes in their native code.

-XX:+UseSIGUSR2 (for SDKs 1.4.0.x and 1.3.1.00 through 1.3.1.12)
Replaced by the -Xusealtsigs option. Instructs the JVM to use SIGUSR2 instead of the default SIGUSR1 to control the behavior of the JVM runtime. When your application requires use of a native code library that uses SIGUSR1, use this option to avoid a conflict between the two runtimes.

The HotSpot VM for Itanium systems uses the following immediate value ranges on break instructions for internal use. Native program code must not execute a break instruction with the immediate operand in any of these ranges,or HotSpot will intercept and interpret the SIGimm signal received by the operating system when the break instruction is encountered.

0x48000 - 0x49000
0x4c000 - 0x80000

Beginning with JDK 1.4 a new feature was added for chaining an application's signal handlers behind the JVM's signal handlers. With signal chaining functionality, applications can now use signals that the JVM uses and not interfere with the JVM's functionality. To obtain this functionality, you need to install a HP-UX patch (described below).

For signal chaining functionality, the application must load the library libjsig.sl before libc.2.

libjsig.sl takes care of signal chaining when the application's signal handlers are installed before or after the VM's handlers get installed. libjsig.sl is not needed when the application installs the handlers before the JVM installs its handlers.

For more information on LD_PRELOAD_ONCE functionality and its limitations, read the man page for dld.sl after you have installed the HP-UX patch.

Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Hewlett-Packard is independent of Sun Microsystems, Inc.