Я столкнулся с ситуацией, когда я не вижу, чтобы какие-либо вызовы методов не записывались приложением VisualVM. Хотел выяснить причину и наткнулся на этот ответ на SO. В третьем пункте упоминается потенциальная проблема метода выборки (это единственный вариант, который я вижу включенным, вероятно, потому, что я делаю удаленное профилирование). В нем упоминаются безопасные точки в коде и безопасный опрос точек по самому коду. Что означают эти термины?
Что такое безопасные точки и безопасный опрос точек в контексте профилирования?
Ответ 1
Проблема неточности инструментов профилирования выборки Java и ее связи с безопасными точками очень хорошо обсуждается в Оценка точности Java Profiler (PLDI'10 ).
По сути, профилировщики Java могут давать неточные результаты при выборке из-за того, что выборка происходит во время безопасных точек. А так как появление защитных точек может быть изменено компилятором, выполнение некоторых методов никогда не будет выполняться пробоотборником. Поэтому профилировщик должен записать образец кода (временной интервал вверх), но он должен дождаться появления точки безопасности. И поскольку безопасная точка, например, перемещенный компилятором, метод, который будет идеально отбираться, никогда не наблюдается.
Как уже объяснялось предыдущим anwer, safepoint является событием или позицией в коде, где компилятор прерывает выполнение, чтобы выполнить некоторый внутренний код VM (например, GC).
Опрос безопасных точек - это метод реализации триггера safepoint или safepoint. Это означает, что в исполняемом коде вы регулярно проверяете флаг, чтобы увидеть, требуется ли выполнение безопасной точки, если да (из-за, например, триггера GC), поток прерывается и выполняется безопасная точка. См. Безопасная точка GC (или safepoint) и безопасная область
Ответ 2
В этом сообщении в блоге обсуждаются безопасные точки. В основном это точки в коде, где JITter допускает прерывания для GC, трассировки стека и т.д.
В сообщении также говорится, что безопасные точки, задерживая образцы стека, не могут встречаться в тех местах, где вам могут понравиться, и что проблема.
По-моему, это небольшая проблема. Вся причина, по которой вы берете образец стека (в отличие от простого экземпляра счетчика программ), - это показать вам все сайты вызовов, ведущие к текущему состоянию, поскольку они, вероятно, будут гораздо более сочными источниками медленности, чем любая программа счетчик делает. (Если это что-то делает. Возможно, вы находитесь в середине ввода-вывода, где ПК не имеет смысла, но сайты вызовов по-прежнему так же важны.) Если образец стека должен ждать несколько циклов, чтобы добраться до безопасной точки, все это означает, что это происходит в конце блока инструкций, а не в середине. Если вы исследуете образец, вы все равно можете понять, что происходит.
Я надеюсь, что писатели-профайлы поймут, что им не нужно потеть по мелочам. Что важнее не пропустить большой материал.