Почему -Xrs снижают производительность

Question

От IBM:

-Xrs

Отключает сигнал обработки в JVM.

-Xrs

Установка -Xrs ™ предотвращает запуск время среды Java от обработки каких-либо внутри или снаружи, генерируемых сигналов, таких как SIGSEGV и SIGABRT. Любые сигналы, которые возникают, обрабатываются обработчиками операционной системы по умолчанию. Отключение обработки сигналов в JVM снижает производительность примерно на 2-4%, в зависимости от приложения.

-Xrs: синхронизация

В системах UNIX, эта опция отключает обработку сигнала в JVM для SIGSEGV, SIGFPE, SIGBUS, SIGILL, SIGTRAP, andSIGABRT сигналов. Тем не менее, JVM по-прежнему обрабатывает сигналы SIGQUIT и SIGTERM, среди прочих. Как и в случае -Xrs, использование -Xrs: sync снижает производительность примерно на 2-4%, в зависимости от приложения.

Примечание: Установка этого параметра предотвращает отвалы не генерируется с помощью виртуальной машины Java для сигналов, таких как SIGSEGV и SIGABRT, потому что виртуальная машина больше не перехватывать эти сигналы.

https://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.aix.70.doc/diag/appendixes/cmdline/Xrs.html

Из моего понимания, -Xrs действительно используется, чтобы предотвратить отвалов от генерируется, когда некоторые сигналы ОС перехватываются.

Поскольку JVM больше не перехвата и обработки этих сигналов, он будет стоять разумеется, это было бы увеличения производительности, не снижения его как утверждает IBM.

Почему -Xrs снижает производительность?

Answer 1

Из-за safepoints и операций VM, а также других оптимизаций, которые JIT может выполнять, если вы позволяете управлять сигналами.

JVM иногда должен выполнять некоторые операции, требующие от него приостановить выполнение по всему миру («остановить мир»), например, некоторые крупномасштабные сборки мусора, горячие перезагрузки или внутренние перекомпилирующие классы и т. П. Чтобы сделать это, он должен убедиться, что все запущенные потоки сразу попадают в барьер и приостанавливаются, выполняют операцию, а затем освобождают потоки.

Один из методов, который использует HotSpot (и, вероятно, другие JVM) для реализации safepoints, - это умное злоупотребление segfaults: он создает страницу памяти, которая фактически не используется для каких-либо данных, и затем каждый поток периодически пытается прочитать из этого стр. Когда никакой операции VM не требуется, чтение выполняется с очень низкими накладными расходами, и поток просто продолжает работать.

Когда JVM делает, необходимо выполнить операцию виртуальной машины, это делает недействительной эту страницу памяти.The next time each thread hits a safepoint, it now causes a segfault, что позволяет JVM восстановить контроль выполнения этого потока; он выполняется до тех пор, пока операция VM не будет выполнена, сбросит страницу часового и перезапустит все потоки.

Когда вы отключите обработку SIGSEGV, JVM должна использовать другие методы для синхронизации безопасных точек, которые менее эффективны, чем делегирование встроенной памяти процессора.

Кроме того, JVM делает некоторую серьезную магию с профилированием (по существу, аналогично предсказателю ветвления процессора). Одна из оптимизаций, которые он использует, заключается в том, что если он обнаруживает, что определенная проверка нуля почти никогда не является нулевой, она возвращает проверку и полагается на segfault (дорогостоящий, но в редких случаях), чтобы поймать нуль. Эта оптимизация также требует индивидуальной обработки SIGSEGV.

Answer 2

В дополнение к safepoints, упомянутым обработчиками @chrylis segfault, также используются для других умных трюков оптимизации, таких как неявная проверка нулевого указателя (по крайней мере, они находятся на горячей точке). Если профили показывают, что пул кодов с нулевой проверкой редко запускается, он оптимизируется, и тогда маловероятный случай покрывается обработчиком сигнала.

Такая оптимизация не может быть выполнена без установки специального обработчика сигнала.