Профилирование Java: под покровом

Запустил этот профилировщик против моего надуманного «Привет, мир!» приложение приводит к следующему выводу:

CannotCompileException: no method body; instrumenting method java.lang.Object.wait(long); method will not be instrumented
CannotCompileException: no method body; instrumenting method java.lang.Object.notifyAll(); method will not be instrumented
CannotCompileException: no method body; instrumenting method java.lang.Object.getClass(); method will not be instrumented
CannotCompileException: no method body; instrumenting method java.lang.Object.clone(); method will not be instrumented
CannotCompileException: no method body; instrumenting method java.lang.Object.hashCode(); method will not be instrumented
CannotCompileException: no method body; instrumenting method java.lang.Object.notify(); method will not be instrumented
Thread 'main' entering method 'main' of class 'HelloWorld'
Thread 'main' entering method 'setName' of class 'HelloWorld'
Thread 'main' exiting method 'setName' of class 'HelloWorld'
Thread 'main' entering method 'emitGreeting' of class 'HelloWorld'
Hello, world!
Thread 'main' exiting method 'emitGreeting' of class 'HelloWorld'
Thread 'main' exiting method 'main' of class 'HelloWorld'

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

Это оно! Если вы добавите дополнительную информацию к вызову уведомления (например, получите ThreadMXBean  и получите  текущее значение времени процессора потока), вы сможете увидеть, как вы можете быть на пути к созданию функционального профилировщика. Более того, вы можете целенаправленно ориентировать его на предоставление только той информации, которая вам нужна, только на тех точках касания, которые вы хотите, с гибкостью, которую было бы очень трудно достичь с помощью профилировщика «черного ящика».

Присоединение к запущенному приложению

Ранее я упоминал, что эта функция, хотя и поддерживается, зависит от реализации. В этом разделе я укажу вам информацию, которую необходимо прикрепить к виртуальной машине Sun HotSpot.

Если вы использовали инструменты JDK, такие как Java VisualVM или JConsole , вы видели API присоединения на работе. Если вы собираетесь присоединиться к запущенному процессу, вам нужно получить дескриптор для него (в частности , VirtualMachineDescriptor ), который подразумевает метод для перечисления процессов (см. VirtualMachine.list () ). Это дескрипторы процесса, которые вы видите в диалоговых окнах подключения вышеупомянутых инструментов во время запуска. Лучше всего начать с изучения документации API для com.sun.tools.attach . Эту информацию можно найти в документации по инструментам для загрузки документации JDK или онлайн. Оттуда, посмотрите на документацию для com.sun.tools.attach.VirtualMachine класс — он дает план для начала. Я начну с этого, указывая на некоторые проблемы, с которыми вы можете столкнуться по пути.

Основной процесс изложен ниже:

• Создайте открытый статический метод void agentmain () в своем агенте профилирования (если вы уже создали агент профилирования во время запуска, он может содержать ту же логику, что и ваш  метод premain () ).

• Добавьте   атрибут Agent-Class: в файл манифеста вашего профилировщика, указав полное имя вашего класса профилировщика.

• В вашем приложении запуска выполните следующие шаги:

  1. Получите дескриптор для целевой JVM.

  2. Получите   экземпляр VirtualMachine с помощью  статического метода VirtualMachine.attach () .

  3. Загрузите агент профилирования в целевую JVM с помощью  метода VirtualMachine.loadAgent () .

  4. Отсоединиться от целевой JVM.

В этот момент  будет вызван метод agentmain () вашего профайлера,  и вы будете в бизнесе.

Ниже приведен пример кода, который будет выполнять эти шаги:

try
{
VirtualMachine vm = VirtualMachine.attach(pid);
// load agent into target VM
vm.loadAgent(agentPath);
// detach
vm.detach();
}
catch (AgentInitializationException aie)
{
System.err.println("AgentInitializationException: " + aie.getMessage());
aie.printStackTrace();
}
catch (AgentLoadException ale)
{
System.err.println("AgentLoadException: " + ale.getMessage());
ale.printStackTrace();
}
catch (AttachNotSupportedException anse)
{
System.err.println("AttachNotSupportedException: " + anse.getMessage());
anse.printStackTrace();
}
catch (IOException ioe)
{
System.err.println("IOException: " + ioe.getMessage());
ioe.printStackTrace();
}

 
Хотя я не предоставляю здесь полнофункциональный пример профилировщика, который использует API присоединения, приведенный выше код взят из профилировщика MonkeyWrench с открытым исходным кодом (который будет обсуждаться в следующей статье). Для получения более подробной информации о возможных проблемах, которые могут возникнуть при использовании этого API (и решений!), См. Мой пост «Инструментарий запуска процессов Java с помощью API com.sun.tools.attach » по адресу  http://wayne-adams.blogspot.com. /2009/07/instrumenting-running-java-processes.html .

Последние мысли

Теперь, когда у вас есть базовая структура профилировщика, вот некоторые замечания и идеи.

As I alluded to earlier, you can get a reference to the ThreadMXBean on your method entry and exit notifications. Since you can get the ID of the current thread, you can query the MXBean and retrieve its ThreadInfo object and other properties. This will give you the thread’s accumulated CPU time and the stack trace, among other things. If you want to profile CPU time, you should keep in mind that you’ll need the full method or constructor signature (parameters included), class name, and thread ID to uniquely identify the trace of execution in and out of a method. Also, to correctly handle recursive method calls, when you match an exit notification with an entry notification, you’ll have to unroll the pending method entry notifications by most-recent-entry first, in order to match the correct entry with the exit.

The stack trace information is useful because it allows you to build profiles of the paths used to reach the method or constructor you’re profiling. These profiles are called «sites» in hprof, the very useful but rather expensive profiling agent provided with the JDK. Your profiler can maintain a list of unique stack traces for each method invocation and provide a summary of the sites and their relative frequency as execution progresses.

If you’re profiling constructor activity and are interested in the sizes of objects being instantiated, the Instrumentation class has a getObjectSize() method. The API docs say that this size is implementation-dependent and an approximation. The size appears to be a shallow-copy object size.

This concludes our survey of the instrumentation API provided by the JDK. While a compact package, java.lang.instrument, in conjunction with a good bytecode-injection library, provides everything you need to get started writing a profiler of your own. Even if you don’t find yourself in the position of needing to write a profiler, knowing a little about how to do so will no doubt make you appreciate Java VisualVM or hprof — or your licensed commercial profiler — a little more than you did before!