Побочные эффекты запуска JVM в режиме отладки

Question

Я хотел бы выпустить Java-приложение в режиме отладки, чтобы упростить отладку, когда на стороне клиента возникают случайные или трудно воспроизводимые проблемы.

Однако я хочу получить представление о потенциалепобочные эффекты этого?Из документации Java HotSpot кажется, что не должно быть потери производительности .

По ссылке

Отладка на полной скорости

Виртуальная машина Java HotSpot теперь использует отладку на полной скорости.В предыдущей версии виртуальной машины, когда была включена отладка, программа выполнялась с использованием только интерпретатора.Теперь все преимущества производительности технологии HotSpot доступны для программ, даже скомпилированного кода.Повышенная производительность позволяет легко отлаживать долго выполняющиеся программы.Это также позволяет проводить тестирование на полной скорости.Как только возникает исключение, отладчик запускается с полной видимостью для источников кода.

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

PS: Я нашел эту статью от AMD, которая подтвердила мое первоначальное подозрение, что оригинальная статья из oricale не показывает полную историю.

Answer 1

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

Представьте себе ситуацию, когда оптимизатор обнаруживает, что часть программы, по-видимому, не требуется и, согласно различным языковым правилам (включая JSR 133), законно удалять, JVM захочет избавиться от него. Единственный недостаток - отладка: удаление кода будет выглядеть странно для человека, проходящего через него (переменные не обновляются, возможно, не останавливаются в строках при переходе), поэтому выбор состоит в том, чтобы отключить указанные оптимизации в этих случаях. То же самое можно сказать и об опциях, таких как объекты, размещенные в стеке, и т. Д., Поэтому, хотя JVM говорит, что она «на полной скорости», на самом деле она ближе к «почти на полной скорости», с некоторыми из более забавных опций, которые невозможно полностью удалить » .

Answer 2

Этот вопрос старый, но он возник, когда я искал какое-либо влияние на производительность, если вы просто оставляете -agentlib: jdwp ... включенным, но не активно отлаживаете.

Сводка: Запуск с параметрами отладки, но без подключения, не должен влиять на скорость (Java 7+).

До того, как java 6 (ish) вы использовали -Xdebug, и это имело определенный эффект, оно отключило JIT!

В java 6 они изменили его на -agentlib и сделали его лучше. Были некоторые ошибки, хотя это приводило к снижению производительности. Вот одна из ошибок, которые были поданы против openjdk, я предполагаю, что были похожие проблемы с версией oracle / sun: https://bugs.openjdk.java.net/browse/JDK-6902182

Обратите внимание, однако, что заявленная цель состоит в том, что простое включение отладки путем открытия порта не должно приводить к снижению производительности.

Похоже, что, по крайней мере в openjdk, ошибки были устранены с помощью Java 7. Я ничего не видел о влиянии на производительность после этого.

Если вы продолжите изучение этого вопроса и обнаружите отрицательные результаты, обратите внимание на версию Java, в которой проводилось тестирование - все, что я видел, было связано с версиями до 7.

Мне бы очень хотелось узнать, сталкивался ли кто-нибудь с проблемами производительности на недавней виртуальной машине, просто оставив порт включенным.

Answer 3

Если вы планируете запускать приложение с включенной удаленной отладкой, это также может повлиять на безопасность. Удаленная отладка оставляет порт на вашей машине открытым, и, подключившись к нему, я могу делать с вашим приложением самые разные забавные вещи.

Answer 4

Программа определенно делает гораздо больше, чем просто работает в режиме отладки, поэтому очевидно, что производительность не может быть одинаковой.Однако, если вы внимательно прочитаете инструкцию, она говорит, что в новой версии может выполняться полностью оптимизированный код, даже если в режиме отладки это было невозможно ранее.Таким образом, новый jvm намного быстрее предыдущего, который может работать только в интерпретируемом режиме, который не требует оптимизации.