LINUX.ORG.RU

Изменить обработчик инструкций в интерпретаторе JVM

 ,


1

4

Хочу с минимальными затратами производительности отслеживать вход и выход из метода. Для этого хотелось бы добавить логгирование в обработчики инструкций вызова и возврата из метода. Ковыряюсь в коде HotSpot'a, но там много всего и непонятно, куда смотреть. Может кто-то сталкивался с похожей проблемой и знает, как ее лучше решить?

Эм... Вы уверены, что делаете всё правильно? #sarcasm mode off

Зачем вам это нужно? Если для профилировки, то лучше таки взять профайлер, намекает К.О.

Если производительность не критична, аспекты вам в помощь. Но, судя по всему, производительность вам действительно важна. С этой т.з., как ни печально, можно всё-таки логировать вызовы руками в нужных местах. Здесь можно поиграться с архитектурной точки зрения и вынести общие места для упрощения их логирования.

bytecode ★★ ()

Эту проблему лучше решить препроцессингом байткода. Обработай байткод и в начале и конце каждого метода (а лучше не каждого, а из белого списка) поставь вызов своего мониторинга. Обрабатывать можно либо после компиляции, либо агентом, тогда не надо ничего менять на диске.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Вариант препроцессинга байткода тоже был отброшен из-за того, что вставка дополнительного байткода добавит времени выполнения. Это все нужно для того, чтобы профилировать приложение в продакшене. Все дело в производительности, она очень критична. Минимальный оверхед должен быть при логировании прямо из интерпретатора. Был вариант написать агента с помощью JVMTI, он был написан, но в таком случае производительность уменьшалась в два раза.

pdip28 ()
Ответ на: комментарий от bytecode

Задача состоит в том, чтобы не вносить изменения в программу, которая будет профилироваться. Можно только использовать или агенты, или форкать JVM. Отслеживание ивентов с помощью агентов оказалось медленным.

pdip28 ()

Хочу с минимальными затратами производительности отслеживать вход и выход из метода

Кто тебе в продакшн даст кастомный хотспот ставить?

Стандартными методами при логгировании всего подряд просадки менее чем в раза добиваться не удавалось. Через аспект вешал хитрожопый логер, который валил всё в память и периодически плевался в сокет на другую машину. Это правда без сохранения параметров, если вываливал параметры то даже с такими финтами просадка была значительной.

ya-betmen ★★★★★ ()
Ответ на: комментарий от bytecode

лал. «я слышал, что ты хочешь отслеживать вход-выход из метода, поэтому я добавил в твои методы еще методов, чтобы отслеживать вызовы методов».

не, чувак, это же очевидно не то.

cdshines ★★★★★ ()
Ответ на: комментарий от ya-betmen

Это херня. Асинхронные логгеры (твой, по сути, реализует тот же подход другим путем) не катят, потому что это все в приложении. Тут надо какой-то способ делать это снаружи (из вм, пусть патчит себе, жалко что ли? если профайлер тормозит.), только так, чтобы служебные вызовы не блокировали выполнение. Но тоже асинхронно.

У нас одно время на тестовом сервере все жутко лагало и падало, мы уже успели на все компоненты погрешить. Потом просто отключили флайт рекордер и все наладилось.

Ну и вообще, все идеи с профайлерами сосут, потому что они сэмплирующие и для исследования странного поведения конкретных вызовов никуда не годятся. ТС, очевидно, хочет сделать трассировщик. Советы типа аспектов и логирования из тела методов - лор, ты можешь больше!

cdshines ★★★★★ ()
Ответ на: комментарий от ya-betmen

Чел хочет трейсить чужое приложение, ya-betmen врывается в тред и спасает положение!

То есть, например, newrelic, takipi etc - тоже херня?

cdshines ★★★★★ ()
Ответ на: комментарий от pdip28

Вариант препроцессинга байткода тоже был отброшен из-за того, что вставка дополнительного байткода добавит времени выполнения.

этот байткод за-jit-ится и заинлайнится, будет ещё быстрее чем если ты пропатчишь jvm

Был вариант написать агента с помощью JVMTI, он был написан, но в таком случае производительность уменьшалась в два раза.

вангую кривые руки

maloi ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.