Why does -Xrs reduce performance

Question

From IBM:

-Xrs

Disables signal handling in the JVM.

-Xrs

Setting -Xrs prevents the J

Answer 1

In addition to safepoints mentioned by @chrylis segfault handlers are also used for other clever optimization tricks such as implicit null pointer checking (at least they're on hotspot). If profiles show that a null-checking code path is rarely triggered it's optimized out and the unlikely case is then covered by the signal handler instead.

Such an optimization cannot be performed without installing a custom signal handler.

Answer 2

Because of safepoints and VM operations, as well as other optimizations that the JIT can do if you allow it to manage signals.

The JVM occasionally has to perform some operations that require it to pause execution globally ("stop the world"), such as certain large-scale garbage collection, hot reloading or internally recompiling classes, and the like. In order to do this, it has to make sure that all running threads hit a barrier and pause at the same time, do the operation, and then release the threads.

One technique that HotSpot (and likely other JVMs) uses to implement safepoints is a clever abuse of segfaults: It sets up a memory page that is not actually used for any data, and then each thread periodically tries to read from that page. When no VM operation is required, the read succeeds with very low overhead and the thread just keeps running.

When the JVM does need to perform a VM operation, it invalidates that memory page. The next time each thread hits a safepoint, it now causes a segfault, which lets the JVM regain control of that thread's execution; it holds until the VM operation is done, resets the sentinel page, and restarts all the threads.

When you disable SIGSEGV handling, the JVM has to use other techniques to synchronize safepoints that are less efficient than delegating to the processor's built-in memory protection.

Additionally, the JVM does some serious magic with profiling (essentially similar to a CPU's branch predictor). One of the optimizations it uses is that if it detects that a certain null check is almost never null, it elides the check and relies on a segfault (expensive, but in such a case rare) to catch the null. This optimization also requires custom handling of SIGSEGV.