-Xrs为什么会降低性能 [英] Why does -Xrs reduce performance
问题描述
来自IBM:
-Xrs
在JVM中禁用信号处理.
Disables signal handling in the JVM.
-Xrs
设置-Xrs可防止Java™运行时环境处理任何内部或外部生成的信号，例如SIGSEGV和SIGABRT.引发的任何信号均由默认操作系统处理程序处理. 根据应用程序的不同，在JVM中禁用信号处理会使性能降低大约2-4％.
Setting -Xrs prevents the Java™ run time environment from handling any internally or externally generated signals such as SIGSEGV and SIGABRT. Any signals that are raised are handled by the default operating system handlers. Disabling signal handling in the JVM reduces performance by approximately 2-4%, depending on the application.
-Xrs:sync
在UNIX系统上，此选项对SIGSEGV，SIGFPE，SIGBUS，SIGILL，SIGTRAP和SIGABRT信号禁用JVM中的信号处理.但是，JVM仍然可以处理SIGQUIT和SIGTERM信号.与-Xrs一样，根据应用程序的不同， -Xrs:sync的使用会使性能降低大约2-4％.
On UNIX systems, this option disables signal handling in the JVM for SIGSEGV, SIGFPE, SIGBUS, SIGILL, SIGTRAP, andSIGABRT signals. However, the JVM still handles the SIGQUIT and SIGTERM signals, among others. As with -Xrs, the use of -Xrs:sync reduces performance by approximately 2-4%, depending on the application.
注意::设置此选项可防止JVM为诸如SIGSEGV和SIGABRT之类的信号生成转储，因为JVM不再拦截这些信号.
Note: Setting this option prevents dumps being generated by the JVM for signals such as SIGSEGV and SIGABRT, because the JVM is no longer intercepting these signals.
据我所知，-Xrs实际上是用来防止在某些OS信号被拦截时生成转储.
From my understanding, -Xrs is really used to prevent dumps from being generated when certain OS Signals are intercepted.
由于JVM不再拦截和处理这些信号，因此可以说这会提高性能，而不是像IBM所声称的那样降低.
Since the JVM is no longer intercepting and handling these signals, it would stand to reason this would increase performance, not decrease it as claimed by IBM.
为什么-Xrs会降低性能?
推荐答案
由于 安全点 和VM操作以及JIT可以执行的其他优化.
Because of safepoints and VM operations, as well as other optimizations that the JIT can do if you allow it to manage signals.
JVM有时必须执行一些操作，这些操作要求它在全局范围内暂停执行(停止世界")，例如某些大型垃圾回收，热重载或内部重新编译类，等等.为此，必须确保所有正在运行的线程都遇到障碍并同时暂停，执行操作，然后释放线程.
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.
HotSpot(以及可能的其他JVM)用于实现安全点的一种技术是对段错误的巧妙滥用:它设置了一个内存页面，该内存页面实际上并未用于任何数据，然后每个线程定期尝试从该页面读取.当不需要VM操作时，读取操作将以非常低的开销成功完成，并且线程将保持运行状态.
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.
当JVM需要执行VM操作时，它将使该内存页面无效. 下次每个线程命中一个安全点，它现在会导致段错误，它使JVM重新获得对该线程执行的控制；它一直保持到VM操作完成为止，重置哨兵页面，然后重新启动所有线程.
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.
当禁用SIGSEGV处理时，JVM必须使用其他技术来同步安全点，而安全点的效率要低于委托给处理器的内置内存保护.
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.
此外，JVM在配置文件方面做了一些严肃的魔术(本质上类似于CPU的分支预测变量).它使用的一种优化方法是，如果检测到某个空检查几乎永远不会为空，则它会取消检查并依靠段错误(昂贵，但在这种情况下很少)捕获空值.此优化还需要对SIGSEGV进行自定义处理.
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.
这篇关于-Xrs为什么会降低性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
