Что нужно делать JVM при вызове метода native?

Каковы обычные шаги, которые должна выполняться во время выполнения JVM при вызове метода Java, объявленного как native?

Как JVM HotSpot 1.8.0 реализует вызов функции JNI? Какие шаги проверки выполняются (например, необработанные исключения после возврата?), В какой бухгалтерии работает JVM (например, локальный реестр?), И где элемент управления проходит после вызова собственного метода Java? Я также был бы признателен, если бы кто-то мог предоставить точку входа или важные методы из собственного кода HotSpot 1.8.0.

Отказ от ответственности: я знаю, что сам читаю код, но предыдущее объяснение помогает быстро найти мой путь через код. Кроме того, я счел этот вопрос целесообразным для поиска в Google.;)

Ответы

Ответ 1

Вызов метода JNI из Java довольно дорого по сравнению с простым вызовом функции C. HotSpot обычно выполняет большинство из следующих шагов для вызова метода JNI:

  • Создайте фрейм стека.
  • Переместить аргументы в соответствующие регистры или местоположения стека в соответствии с ABI.
  • Оберните ссылки на объекты для дескрипторов JNI.
  • Получите JNIEnv* и jclass для статических методов и передайте их в качестве дополнительных аргументов.
  • Проверьте, следует ли вызывать функцию трассировки method_entry.
  • Заблокировать монитор объекта, если метод synchronized.
  • Проверьте, не связана ли родная функция. Поиск функции и привязка выполняются лениво.
  • Отключить поток от in_java до in_native.
  • Вызов функции native
  • Проверьте, требуется ли safepoint.
  • Возвращает поток в состояние in_java.
  • Отключить монитор, если он заблокирован.
  • Сообщить method_exit.
  • Результат объекта unwrap и reset JNI обрабатывает блок.
  • Обработать исключения JNI.
  • Удалите фрейм стека.

Исходный код этой процедуры можно найти в SharedRuntime:: generate_native_wrapper.

Как вы можете видеть, накладные расходы могут быть значительными. Но во многих случаях большинство вышеуказанных шагов не являются необходимыми. Например, если собственный метод просто выполняет некоторую кодировку/декодирование в байтовом массиве и не генерирует никаких исключений и не вызывает другие функции JNI. Для этих случаев HotSpot имеет нестандартное (и неизвестное) соглашение под названием Critical Natives, обсуждаемое здесь.