Войти
| Designer | Sun Microsystems |
|---|---|
| Биты | 32- бит |
| Представлен | 1994 |
| Версия | 14.0.1 |
| Тип | Стек и регистр – регистр |
| Кодирование | Переменная |
| Ветвление | Сравнение и ветвление |
| Порядок байтов | Большой |
| Открыть | Да |
| Регистры | |
| Общее назначение | Стек операндов для каждого метода (до 65535 операндов) плюс локальные переменные для каждого метода (до 65535) |
Обзор архитектуры виртуальной машины Java (JVM) на основе спецификации виртуальной машины Java Java SE 7 Edition A Виртуальная машина Java (JVM ) - это виртуальная машина, которая позволяет компьютеру запускать программы Java, а также программы, написанные на других языках, которые также скомпилированы в Байт-код Java. JVM подробно описывается в спецификации , которая формально описывает, что требуется в реализации JVM. Наличие спецификации обеспечивает возможность взаимодействия программ Java в различных реализациях, так что авторам программ, использующим Java Development Kit (JDK), не нужно беспокоиться об особенностях базовой аппаратной платформы.
Эталонная реализация JVM разработана проектом OpenJDK как код с открытым исходным кодом и включает JIT-компилятор, вызываемый HotSpot. Коммерчески поддерживаемые выпуски Java, доступные от Oracle Corporation, основаны на среде выполнения OpenJDK. Eclipse OpenJ9 - еще одна JVM с открытым исходным кодом для OpenJDK.
Виртуальная машина Java является абстрактной (виртуальной) компьютер определяется спецификацией. Используемый алгоритм сборки мусора и какая-либо внутренняя оптимизация инструкций виртуальной машины Java (их перевод в машинный код) не указаны. Основная причина этого упущения - не ограничивать разработчиков без необходимости. Любое приложение Java может быть запущено только внутри некоторой конкретной реализации абстрактной спецификации виртуальной машины Java.
Начиная с Java Platform, Standard Edition (J2SE) 5.0, изменения в спецификации JVM были разработаны в рамках процесса Java Community Process как JSR 924. Начиная с 2006 года, изменения в спецификации для поддержки изменений, предложенных для формата файла класса (JSR 202), выполняются в качестве обслуживания выпуск JSR 924. Спецификация JVM была опубликована в виде синей книги. В предисловии говорится:
We предполагает, что эта спецификация должна достаточно документировать виртуальную машину Java, чтобы сделать возможными совместимые реализации для чистой комнаты. Oracle предоставляет тесты, которые проверяют правильность работы реализаций виртуальной машины Java.
Одна из JVM Oracle называется HotSpot, другая, унаследованная от BEA Systems, - Дж. Рокит. Чистая комната Реализации Java включают Kaffe, OpenJ9 и CEE-J Скельмира. Oracle владеет товарным знаком Java и может разрешить его использование для сертификации комплектов реализации как полностью совместимых со спецификацией Oracle.
Одной из организационных единиц байтового кода JVM является класс. Реализация загрузчика классов должна уметь распознавать и загружать все, что соответствует формату файла классов Java. Любая реализация может свободно распознавать другие двоичные формы, кроме файлов классов, но она должна распознавать файлы классов.
Загрузчик классов выполняет три основных действия в этом строгом порядке:
В общем, существует два типа загрузчика классов: загрузчик классов начальной загрузки и пользовательский загрузчик классов.
Каждая реализация виртуальной машины Java должна иметь загрузчик классов начальной загрузки, способный загружать доверенные классы. Спецификация виртуальной машины Java не определяет, как загрузчик классов должен находить классы.
JVM оперирует примитивными значениями (целыми числами и числами с плавающей запятой) и ссылками. По сути, JVM - это 32-битная машина. Типы longи double, которые являются 64-битными, поддерживаются изначально, но используют две единицы памяти в локальных переменных кадра или стеке операндов, поскольку каждая единица имеет размер 32 бита. Все типы boolean, byte, shortи charотносятся к расширенному знаку (кроме char, который является расширенным нулем ) и работает как 32-битные целые числа, то же самое, что и типы int. У меньших типов есть только несколько инструкций по загрузке, сохранению и преобразованию типов. booleanобрабатывается как 8-битные байтовыезначения, где 0 представляет false, а 1 представляет true. (Хотя логическоерассматривалось как тип, так как Спецификация виртуальной машины Java, Второе издание разъяснила эту проблему, в скомпилированном и исполняемом коде есть небольшая разница между логическим и байт, за исключением изменения имени в сигнатурах методов и типа логических массивов. логическиев сигнатурах методов искажаются как Zв то время как байтыизменяются как B. Логические массивы несут тип boolean, но используют 8 бит на элемент, а JVM не имеет встроенных возможностей для упаковки логических значений в битовый массив, поэтому, за исключением типа, который они выполняют и ведут себя так же, как массивы byte. Во всех других случаях используется тип booleanфактически неизвестно JVM, поскольку все инструкции для работы с логическими значениями также используются для работы с байтамиs.)
JVM имеет кучу со сборкой мусора для хранения объекты и массивы. Код, константы и другие данные класса хранятся в «области метода». Область метода логически является частью кучи, но реализации могут обрабатывать область метода отдельно от кучи и, например, не могут собирать ее мусором. Каждый поток JVM также имеет свой собственный стек вызовов (для ясности называемый «стеком виртуальной машины Java»), в котором хранятся кадры. Новый фрейм создается каждый раз, когда вызывается метод, и фрейм уничтожается при выходе из этого метода.
Каждый фрейм предоставляет «стек операндов» и массив «локальных переменных». Стек операндов используется для операндов для вычислений и для получения возвращаемого значения вызываемого метода, в то время как локальные переменные служат той же цели, что и регистры , а также используются для передачи аргументов метода. Таким образом, JVM является одновременно стековой машиной и регистровой машиной.
JVM имеет инструкций для следующих групп задач:
Целью является двоичная совместимость. Каждому конкретному хосту операционной системе требуется собственная реализация JVM и среды выполнения. Эти JVM интерпретируют байт-код семантически одинаково, но фактическая реализация может отличаться. Более сложным, чем просто эмуляция байт-кода, является совместимая и эффективная реализация API ядра Java, который должен быть сопоставлен с каждой операционной системой хоста.
Эти инструкции работают с набором общих абстрактных типов данных, а не с собственными типами данных любой конкретной архитектуры набора команд.
Язык JVM - это любой язык, функциональность которого может быть выражена в виде допустимого файла класса, который может быть размещен на виртуальной машине Java. Файл класса содержит инструкции виртуальной машины Java (байт-код Java ) и таблицу символов, а также другую вспомогательную информацию. Формат файла класса - это независимый от оборудования и операционной системы двоичный формат, используемый для представления скомпилированных классов и интерфейсов.
Существует несколько языков JVM, как старые языки, перенесенные на JVM, так и совершенно новые языки. JRuby и Jython, пожалуй, самые известные порты существующих языков, то есть Ruby и Python соответственно. Из новых языков, которые были созданы с нуля для компиляции в байт-код Java, Clojure, Apache Groovy, Scala и Kotlin могут быть самые популярные. Примечательной особенностью языков JVM является то, что они совместимы друг с другом, так что, например, библиотеки Scala могут использоваться с программами Java и наоборот.
Java 7 JVM реализует JSR 292: Поддержка динамически типизированных языков на платформе Java, новая функция, которая поддерживает динамически типизированные языки в JVM. Эта функция разработана в рамках проекта Da Vinci Machine, задача которого - расширить JVM таким образом, чтобы она поддерживала языки, отличные от Java.
Основная философия Java заключается в том, что он по своей сути безопасен с точки зрения того, что никакая пользовательская программа не может вызвать сбой хост-машины или иным образом несоответствующим образом вмешаться в другие операции на хост-машине, и что можно защитить определенные методы и структуры данных, принадлежащие доверенному коду, от доступа или повреждение ненадежным кодом, выполняемым в той же JVM. Кроме того, недопустимы распространенные ошибки программиста, которые часто приводят к повреждению данных или непредсказуемому поведению, например, доступ к концу массива или использование неинициализированного указателя. Для обеспечения этой безопасности объединяются несколько функций Java, в том числе модель классов, куча со сборкой мусора и верификатор.
JVM проверяет весь байт-код перед его выполнением. Эта проверка состоит в основном из трех типов проверок:
Первые две из этих проверок происходят в основном на этапе проверки, который происходит, когда класс загружается и становится пригодным для использования. Третий в основном выполняется динамически, когда к элементам данных или методам класса сначала обращается другой класс.
Верификатор разрешает только некоторые последовательности байт-кода в допустимых программах, например команда перехода (перехода) может нацеливаться только на инструкцию в том же методе. Кроме того, верификатор гарантирует, что любая данная инструкция работает в фиксированном месте стека, позволяя JIT-компилятору преобразовывать обращения к стеку в обращения к фиксированным регистрам. По этой причине то, что JVM представляет собой стековую архитектуру, не подразумевает потери скорости для эмуляции на регистровых архитектурах при использовании JIT-компилятора. Перед лицом архитектуры JVM с проверкой кода для JIT-компилятора не имеет значения, получает ли он именованные мнимые регистры или мнимые позиции стека, которые должны быть выделены регистрам целевой архитектуры. Фактически, проверка кода отличает JVM от классической стековой архитектуры, эффективная эмуляция которой с помощью JIT-компилятора более сложна и обычно выполняется более медленным интерпретатором.
Исходная спецификация для верификатора байт-кода использовала естественный язык, который был неполным или неверным в некоторых отношениях. Было сделано несколько попыток определить JVM как формальную систему. Таким образом можно более тщательно проанализировать безопасность текущих реализаций JVM и предотвратить возможные взломы. Также можно будет оптимизировать JVM, пропустив ненужные проверки безопасности, если будет доказано, что запущенное приложение безопасно.
Архитектура виртуальной машины позволяет очень хорошо Детализированный контроль над действиями, которые разрешено выполнять коду внутри машины. Он предполагает, что код «семантически» правильный, то есть успешно прошел (формальный) процесс проверки байт-кода, материализованный инструментом, возможно, за пределами виртуальной машины. Это разработано, чтобы обеспечить безопасное выполнение ненадежного кода из удаленных источников, модель, используемую Java-апплетами, и другие безопасные загрузки кода. После проверки байт-кода загруженный код запускается в ограниченной «песочнице », которая предназначена для защиты пользователя от неправильного поведения или вредоносного кода. В дополнение к процессу проверки байт-кода издатели могут приобрести сертификат, с помощью которого можно поставить цифровую подпись апплетов как безопасную, дав им разрешение попросить пользователя выйти из песочницы и получить доступ к локальной файловой системе, буфер обмена, выполнение внешних программ или сети.
Формальное подтверждение верификаторов байт-кода было сделано в индустрии Javacard (формальная разработка встроенного верификатора для байт-кода карты Java)
Для каждой аппаратной архитектуры требуется свой интерпретатор байт-кода Java . Когда компьютер имеет интерпретатор байт-кода Java, он может запускать любую программу байт-кода Java, и ту же программу можно запускать на любом компьютере, на котором есть такой интерпретатор.
Когда байт-код Java выполняется интерпретатором, выполнение всегда будет медленнее, чем выполнение той же программы, скомпилированной на машинном языке. Эта проблема смягчается с помощью JIT-компиляторов для выполнения байт-кода Java. Компилятор JIT может переводить байт-код Java на собственный машинный язык во время выполнения программы. После этого переведенные части программы можно будет выполнить гораздо быстрее, чем их можно будет интерпретировать. Этот метод применяется к тем частям программы, которые часто выполняются. Таким образом, JIT-компилятор может значительно ускорить общее время выполнения.
Нет необходимой связи между языком программирования Java и байт-кодом Java. Программа, написанная на Java, может быть скомпилирована непосредственно на машинный язык реального компьютера, а программы, написанные на языках, отличных от Java, могут быть скомпилированы в байт-код Java.
Байт-код Java не зависит от платформы и безопасен. Некоторые реализации JVM не включают интерпретатор, а состоят только из оперативного компилятора.
В начале жизненного цикла платформы Java JVM была продается как веб-технология для создания многофункциональных Интернет-приложений. По состоянию на 2018 г. большинство веб-браузеров и операционных систем, объединяющих веб-браузеры, не поставляются с подключаемым модулем Java и не разрешают боковую загрузку любых файлов, отличных от Flash плагин. Подключаемый модуль браузера Java устарел в JDK 9.
Подключаемый модуль браузера Java NPAPI был разработан, чтобы позволить JVM выполнять так называемые апплеты Java, встроенные в страницы HTML.. Для браузеров с установленным подключаемым модулем апплету разрешено рисовать в прямоугольной области на странице, назначенной ему. Поскольку подключаемый модуль включает JVM, апплеты Java не ограничиваются языком программирования Java; любой язык, предназначенный для JVM, может работать в подключаемом модуле. Ограниченный набор API-интерфейсов позволяет апплетам получать доступ к микрофону пользователя или к 3D-ускорению, хотя апплеты не могут изменять страницу за пределами ее прямоугольной области. Adobe Flash Player, основная конкурирующая технология, работает в этом отношении точно так же.
По данным W3Techs, по состоянию на июнь 2015 года использование Java-апплетов и Silverlight для всех веб-сайтов упало до 0,1% каждый, а Flash - до 10,8%.
По состоянию на май 2016 года JavaPoly позволяет пользователям импортировать немодифицированные библиотеки Java и вызывать их непосредственно из JavaScript. JavaPoly позволяет веб-сайтам использовать немодифицированные библиотеки Java, даже если на компьютере пользователя не установлена Java.
С постоянным улучшением скорости выполнения JavaScript в сочетании с увеличением при использовании мобильных устройств, веб-браузеры которых не поддерживают плагины, предпринимаются попытки нацелить на этих пользователей компиляцию в JavaScript. Можно скомпилировать исходный код или байт-код JVM в JavaScript.
Компиляция байт-кода JVM, который является универсальным для языков JVM, позволяет создавать байт-код на основе существующего компилятора языка. Основным байт-кодом JVM для компиляторов JavaScript являются TeaVM, компилятор, содержащийся в Dragome Web SDK, Bck2Brwsr и j2js-compiler.
Ведущие компиляторы с языков JVM на JavaScript включают компилятор Java-to-JavaScript, содержащийся в Google Web Toolkit, Clojurescript (Clojure ), GrooScript (Apache Groovy ), Scala.js (Scala) и другие.
Среда выполнения Java (JRE), выпущенная Oracle, представляет собой свободно доступный дистрибутив программного обеспечения, содержащий автономную JVM (HotSpot ), стандартную библиотеку Java (Библиотека классов Java ), инструмент настройки и - до его прекращения в JDK 9 - подключаемый модуль браузера. Это наиболее распространенная среда Java, устанавливаемая на персональных компьютерах портативных и настольных ПК форм-фактора. Мобильные телефоны, включая телефоны с функциями и первые смартфоны, которые поставляются с JVM, скорее всего, будут включать JVM, предназначенную для запуска приложений, ориентированных на Micro Edition платформы Java. Между тем, большинство современных смартфонов, планшетных компьютеров и других портативных ПК, на которых запущены приложения Java, скорее всего, будут делать это благодаря поддержке операционной системы Android, которая включает виртуальную машину с открытым исходным кодом, несовместимую со спецификацией JVM. (Вместо этого инструменты разработки Google для Android принимают программы Java в качестве ввода и вывода байт-код Dalvik, который является собственным форматом ввода для виртуальной машины на устройствах Android.)
Спецификация JVM дает разработчикам большую свободу действий в отношении деталей реализации. Начиная с Java 1.3, JRE от Oracle содержит JVM под названием HotSpot. Он был разработан как высокопроизводительная JVM.
Чтобы ускорить выполнение кода, HotSpot полагается на своевременную компиляцию. Чтобы ускорить выделение объектов и сборку мусора, HotSpot использует кучу поколений.
Куча виртуальной машины Java - это область памяти, используемая JVM для распределения динамической памяти.
В HotSpot куча разделяется на поколения:
Постоянное поколение (или перманент) использовалось для определений класса и связанных метаданных до Java 8. Постоянное поколение не было частью кучи. Постоянная генерация была удалена из Java 8.
Первоначально постоянной генерации не было, и объекты и классы хранились вместе в одной области. Но поскольку выгрузка классов происходит гораздо реже, чем собираются объекты, перемещение структур классов в определенную область позволило значительно улучшить производительность.
Oracle JRE установлена на большом количестве компьютеров. Таким образом, конечные пользователи с устаревшей версией JRE уязвимы для многих известных атак. Это привело к широко распространенному мнению, что Java по своей сути небезопасна. Начиная с Java 1.7, Oracle JRE для Windows включает функцию автоматического обновления.
До прекращения поддержки подключаемого модуля Java-браузера на любой веб-странице потенциально мог быть запущен Java-апплет, который обеспечивал легкодоступную поверхность атаки для вредоносных веб-сайтов. В 2013 году «Лаборатория Касперского» сообщила, что компьютерные злоумышленники предпочитают плагин Java. Эксплойты Java включены во многие пакеты эксплойтов, которые хакеры размещают на взломанных веб-сайтах. Аплеты Java были удалены из Java 11, выпущенного 25 сентября 2018 г.
Портал компьютерного программирования 