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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это херня

Похоже что чел хочет трейсить чужое приложение - вот где херня.

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

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

Пробовали Java Flight Recorder? оно нормально профилирует на проде. Не знаю какие у вас требования к производительность, но стоит попробовать http://www.oracle.com/technetwork/java/embedded/resources/tech/java-flight-re...

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

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

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

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