From IBM:
-Xrs
Disables signal handling in the JVM.
-Xrs
Setting -Xrs prevents the J
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.