Почему Java-байт-код интерпретируется?

Question

Насколько я понимаю, Java компилируется в байт-код Java, который затем может быть интерпретирован любой машиной, на которой запущена Java, для конкретного процессора. Java использует JIT для интерпретации байт-кода, и я знаю, что он стал очень быстрым при этом, но почему разработчики языка просто не статически компилируют машинные инструкции, как только обнаруживают конкретную машину, на которой работают? Интерпретируется ли байт-код при каждом прохождении кода?

Answer 1

Первоначальный дизайн был в предположении, что «скомпилируйте один раз где-нибудь». Таким образом, каждый разработчик виртуальной машины может запускать байт-коды, сгенерированные компилятором.

В книге вдохновители программирования , Джеймс Гослинг объяснил:

Джеймс : Точно. В эти дни мы бить действительно хорошие C и C ++ компиляторы почти всегда Когда ты перейти к динамическому компилятору, вы получите два преимущества, когда компилятор работает прямо в последний момент. Один Вы точно знаете, какой чипсет ты бежишь дальше. Так много раз, когда люди собирают кусок C код, они должны скомпилировать его для запуска на вид общего x86 архитектура. Почти никто из двоичные файлы, которые вы получаете, особенно хорошо настроенный на любой из них. Вы скачиваете последняя копия Mozilla, и это будет работать практически на любом Intel Архитектура процессора. Там довольно много один бинарный Linux Это довольно общее, и это скомпилировано с GCC, который не очень хороший компилятор Си.

Когда работает HotSpot, он точно знает на каком чипсете вы работаете. Это точно знает, как работает кеш. Это точно знает, как иерархия памяти работает. Он точно знает, как все работа конвейерной блокировки в процессоре. Он знает, что набор инструкций У этого чипа есть расширения. Это оптимизирует именно для какой машины Вы на. Тогда другая половина является то, что он на самом деле видит приложение работает. Это в состоянии иметь статистику, которая знает, какие вещи важны. Это в состоянии встроенные вещи, которые мог компилятор C никогда не делай. Вид вещей, которые получают встраивается в мир Java довольно удивительно. Затем вы придерживаетесь этого способ управления хранением с современные сборщики мусора. С современный сборщик мусора, склад распределение очень быстро.

Answer 2

Java обычно компилируется в машинные инструкции; Вот что такое JIT-компиляция. Но Java-реализация Sun по умолчанию делает это только для кода, который выполняется достаточно часто (поэтому байт-код запуска и завершения, который выполняется только один раз, все еще интерпретируется для предотвращения издержек JIT).

Answer 3

Интерпретация байт-кода обычно достаточно быстра для многих случаев. Компиляция, с другой стороны, довольно дорогая. Если 90% времени выполнения тратится на 1% кода, гораздо лучше просто скомпилировать этот 1% и оставить остальные 99% в покое.

Answer 4

Статическая компиляция может взорвать вас, потому что все другие библиотеки, которые вы используете, также должны запускаться везде с однократной записью (например, байт-код), включая все их зависимости. Это может привести к цепочке компиляций, следующих за зависимостями, которые могут взорвать вас. Я думаю, что компиляция только кода, когда (во время выполнения) среда выполнения обнаруживает, что ему действительно нужен этот скомпилированный раздел кода, является основной идеей. Может быть много путей кода, которые вы на самом деле не используете, особенно когда речь идет о библиотеках.

Answer 5

Java-байт-код интерпретируется потому, что байт-коды переносимы на различные платформы. JVM, которая зависит от платформы, преобразует и выполняет байт-коды в конкретный набор команд этой машины, будь то Windows, LINUX или MAC и т. Д. *

Answer 6

Одним из важных отличий динамической компиляции является то, что она оптимизирует базовую часть кода и способ его запуска. Существует опция -XX:CompileThreshold=, которая по умолчанию равна 10000. Вы можете уменьшить это, чтобы он быстрее оптимизировал код, но если вы запустите сложное приложение или тест, вы обнаружите, что уменьшение этого числа может привести к замедлению кода. Если вы запустите простой тест, вы, возможно, не обнаружите, что это имеет какое-либо значение.

Одним из примеров, где динамическая компиляция имеет преимущество перед статической компиляцией, является встраивание «виртуальных» методов, особенно тех, которые можно заменить. Например, JVM может встроить до двух активно используемых «виртуальных» методов, которые могут быть скомпилированы в отдельный jar-файл после компиляции вызывающей стороны. Вызываемые банки могут быть даже удалены из работающей системы, например OSGi и добавьте другую банку или замените ее. Методы замены JAR могут быть встроены. Этого можно добиться только с помощью динамической компиляции.