спецификации, руководства, описания, API

Архитектура Отладчика Платформы Java

Краткий обзор

Архитектура Отладчика Платформы Java (JPDA) состоит из двух интерфейсов (TI JVM и JDI), протокол (JDWP) и два компонента программного обеспечения, которые связывают их (бэкэнд и фронтэнд). TI JVM является новым интерфейсом, представленным в J2SE 5.0, который заменяет JVMDI. Намерение является многократным:

Обеспечить стандартные интерфейсы (ради простоты мы будем именовать JDWP как интерфейс), которые позволяют средствам отладки языка программирования Java быть просто написанными без отношения к специфическим особенностям платформы такие аппаратные средства, операционная система и реализация виртуальной машины.
Описать полную архитектуру для того, чтобы реализовать эти интерфейсы, включая удаленную и межплатформенную отладку.
Обеспечить ссылочную реализацию этой архитектуры.
Обеспечить очень модульную архитектуру, где реализация и/или клиент интерфейса могут отличаться чем ссылочная реализация или могут отличаться от компонента JPDA.

Фон

См. Архитектуру Отладчика Платформы Java.

Модульный принцип

Детали модульной структуры JPDA обсуждаются ниже. В каждом случае описывается стандартное использование JPDA. Ссылочная реализация описывается и альтернативные реализации, и клиенты интерфейса обсуждаются.

Модульный принцип TI JVM

Интерфейс Инструмента виртуальной машины Java (TI JVM) описывает функциональность, обеспеченную виртуальной машиной (VM), чтобы позволить отлаживать приложений языка программирования Java, работающих под этим VM. В JPDA TI JVM реализуется VM, и клиент является бэкэндом JPDA. В ссылочной реализации JPDA TI JVM реализуется Java HotSpot, VM и клиент являются ссылочной реализацией бэкэнда, предоставленного как собственная совместно используемая библиотека (jdwp.so, jdwp.dll...), который поставляется с JDK.

Много VMs кроме Java HotSpot VM реализуют TI JVM. Ссылочная реализация бэкэнда была портирована на другие платформы. И есть клиенты TI JVM кроме бэкэнда, наиболее особенно агенты для приложений, которые позволяют отлаживать и собственного и код языка программирования Java, и таким образом нуждаются в собственном управлении уровнем и информации. Мы не знаем ни о каких реализациях чистой комнаты бэкэнда, хотя это возможно - и большая работа.

Модульный принцип JDWP

Протокол Провода Отладки Java (JDWP) описывает формат отладочной информации и запросов между отлаживаемой программой и отладчиком. В JPDA есть канал связи между фронтэндом (в процессе отладчика) и бэкэндом (в процессе отлаживаемой программы) - формат данных, текущих на этом канале, описывается JDWP. В ссылочной реализации JPDA ссылочная реализация бэкэнда (выше) предоставляет стороне отлаживаемой программы этого канала, и ссылочная реализация фронтэнда (компонент языка программирования Java JDK, расположенного в tools.jar), предоставляет стороне отладчика.

TI JVM проблематичен, чтобы реализовать в некотором VMs. JDWP реализуется непосредственно в таком VMs. На стороне клиента приложение, записанное на языке кроме языка программирования Java, возможно, не оптимальный кандидат на использование JDI. Некоторые хотели быть клиентами JDWP.

Модульный принцип JDI

Интерфейс Отладки Java (JDI) обеспечивает чистый интерфейс языка программирования Java для того, чтобы он отладил приложения языка программирования Java. В JPDA JDI является удаленным представлением в процессе отладчика виртуальной машины в процессе отлаживаемой программы. Это реализуется фронтэндом (выше), в то время как подобное отладчику приложение (IDE, отладчик, трассировщик, контролируя инструмент...) является клиентом.

JDI мог быть реализован системой со статичным представлением приложения. Это могло быть реализовано системой с механизмом, совершенно отличающимся чем JDWP/front-end для того, чтобы собрать информацию или управлять VM.

Обход - через

Различные способы, которыми могут использоваться интерфейсы, обсуждаются выше. Этот раздел исследует, как стандартный полный JPDA работает. Примеры проникают в детали об определенных вызовах и кодах. Не важно понять их - они присутствуют только, чтобы сделать примеры более конкретными.

Через каждый интерфейс есть два класса действия: запросы и события. Запросы происходят на стороне отладчика и включают запросы для информации, установки изменений состояния в удаленном VM/application, и установки отладки состояния. События происходят на стороне отлаживаемой программы и обозначают изменения состояния в удаленном VM/application.

Давайте идти через пример. Пользователь щелкает по локальной переменной в представлении стека в IDE, запрашивая его значение. IDE использует JDI, чтобы получить значение, в особенности это вызывает getValue метод, например:

    theStackFrame.getValue(theLocalVariable)

Где theStackFrame a com.sun.jdi.StackFrame и theLocalVariable a com.sun.jdi.LocalVariable.

Фронтэнд тогда отправляет этот запрос по коммуникационному каналу (скажем, сокет) к бэкэнду, работающему в процессе отлаживаемой программы. Это отправляет это, форматируя это в поток байтов в соответствии с JDWP. В частности это отправляет команду GetValues (значение байта: 1) в наборе команд StackFrame (значение байта: 16), сопровождаемый ID потока, ID фрейма, и т.д.

Бэкэнд дешифрует поток байтов и отсылает запрос к VM через TI JVM. В частности скажем, требуемое значение является целым числом, следующий вызов функции TI JVM делается:

    error = jvmti->GetLocalInt(frame, slot, &intValue);

Бэкэнд отсылает назад через сокет, пакет ответа, который будет включать значение intValue, и который будет отформатирован согласно JDWP. Фронтэнд дешифрует пакет ответа и возвращает значение как значение getValue вызов метода. IDE тогда выводит на экран значение.

Запросы, чтобы изменить состояние отладки обрабатываются подобным образом. Например, запрос, чтобы установить контрольную точку проходит через те же самые шаги - хотя, конечно, вызванные методы JDI, команды JDWP, отправленные, и вызванные функции TI JVM, отличаются. Дополнительно, фронтэнд и бэкэнд действительно более чем пихают данные назад и вперед, они отслеживают и планируют действие и преобразовывают, фильтруют, и информация о кэше, таким образом, запрос контрольной точки будет обработан вполне по-другому, чем получить запрос значения - но коммуникационная последовательность будет тем же самым.

Что происходит, когда приложение, отлаживаемое наконец, поражает эту контрольную точку? Это - то, где события играют роль. Виртуальная машина отправляет событие через интерфейс TI JVM. В частности это вызывает функцию обработки событий передача контрольной точки:

Бэкэнд установил функцию обработки событий, чтобы быть:

static void Breakpoint(jvmtiEnv *jvmti_env,
                       JNIEnv* jni_env, jthread thread,
                       jmethodID method, jlocation location)
{ ...

Эта функция бэкэнда запускает цепочку действия, которое фильтрует событие, чтобы видеть, интересно ли это, ставит это в очередь, и отправляет это через сокет в формате JDWP, определенном для событий контрольной точки. Фронтэнд декодирует и обрабатывает событие, в конечном счете генерируя событие JDI. В частности событие JDI представляет это как a com.sun.tools.jdi.event.BreakpointEvent. IDE тогда получает событие, удаляя это из очереди событий:

    theEventQueue.remove()

где theEventQueue a com.sun.jdi.event.EventQueue. IDE, вероятно, обновит свои дисплеи, выполняя много вызовов запроса через JDI.

Портирование

Каждая реализация виртуальной машины нуждается в своей собственной реализации TI JVM - реализация TI JVM должна вырыть глубоко в структуры данных VM и должна установить рычаги в реализацию VM, чтобы получить события. Добавление JVMDT к VM без поддержки TI JVM является существенным обязательством. В зависимости от сложности VM и количества дополнительного реализованного TI JVM, это мог бы быть проект трех - двенадцати месяцев. Портирование VM, у которого есть поддержка TI JVM новой платформе, является прежде всего работой портирования частей TI не-JVM VM - TI JVM добавляет сравнительно небольшое количество работы.

Ссылочная реализация бэкэнда может обычно перемещаться в новую платформу с немного (несколько строк) или никакое изменение к источнику и затем перекомпилирована. Чтобы использовать новый VM на той же самой платформе, двоичный файл бэкэнда должен обычно работать - хотя, это не код языка программирования Java, таким образом, Вы никогда не знаете. Отметьте, что лицензирующие проблемы не охватываются этим документом.

Реализация фронтэнда пишется в языке программирования Java и будет работать на любой платформе или VM. Однако, у кода соединителя есть функциональность, которая, возможно, должна быть расширена для некоторых систем. Например, ссылочная реализация фронтэнда включает средство запуска, которое предполагает, что виртуальные машины запускаются, используя Java соглашения SE. Пользователь JDI может сконфигурировать любой синтаксис средства запуска, который он или она хочет, но обычно приложение отладчика предпочло бы оставлять это реализации JDI. Если бы различный тип канала связи требуется (последовательный, например), это также должно было бы быть добавлено, используя Интерфейс Поставщика услуг, представленный в JDK 5.0.

Свяжитесь с Нами