Динамическая компиляция - краткая история

Тема 1. Краткое описание особенностей языка Java

Принцип работы

Исходный код любой программы на языке Java представляется обычными текстовыми файлами, которые могут быть созданы в любом текстовом редакторе или специализированном средстве разработки и имеют расширение .java. Эти файлы подаются на вход Java -компилятора, который транслирует их в специальный Java байт-код. Результат работы компилятора сохраняется в бинарных файлах с расширением .class. Java -приложение, состоящее из таких файлов, подается на вход виртуальной машине, которая начинает их исполнять, или интерпретировать, так как сама является программой.

Рисунок 1 – Принцип разработки Java программ

Динамическая компиляция - краткая история

Процесс компиляции Java -приложения отличается от процесса компиляции статически компилируемых языков программирования, подобных С или С++. Статический компилятор преобразует исходный код непосредственно в машинные инструкции, которые могут быть выполнены на целевой платформе. Различные аппаратные платформы требуют применения различных компиляторов [2].

Java -компилятор преобразует исходный Java -код в переносимые байт-коды JVM, которые являются для JVM "инструкциями виртуальной машины". В отличие от статических компиляторов javac выполняет очень маленькую оптимизацию - оптимизация, проводимая статическими компиляторами, выполняется во время исполнения программы.

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

Just-in-time (оперативная) компиляция

Интерпретация была хороша для proof-of-concept (доказательство идеи) реализации, но первые JVM сразу обвинили в медлительности. Следующие поколения JVM использовали just-in-time (JIT) компиляторы для ускорения работы. Строго определенная JIT -виртуальная машина перед выполнением преобразовывает все байт-коды в машинный код, но делает это в неторопливом стиле: JIT компилирует code path только тогда, когда знает, что code path будет сейчас выполняться (отсюда и название just-in-time компиляция). Этот подход дает возможность программам стартовать быстрее, поскольку не требуется длительная фаза компиляции перед возможным началом исполнения кода.

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

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

Динамическая компиляция HotSpot

Исполняющий процесс HotSpot объединяет интерпретацию, профилирование и динамическую компиляцию. Вместо преобразования всех байт-кодов в машинный код HotSpot начинает работу как интерпретатор и компилирует только "горячий" код, то есть код, выполняющийся наиболее часто. Во время выполнения он собирает данные анализа. Эти данные используются для определения фрагментов кода, выполняющихся достаточно часто и заслуживающих компиляции. Компиляция только часто исполняемого кода имеет несколько преимуществ: не тратится время на компиляцию кода, выполняющегося редко, таким образом, компилятор может тратить больше времени на оптимизацию "горячего" кода, поскольку он знает, что время будет потрачено не зря. Кроме того, откладывая компиляцию, компилятор имеет доступ к данным анализа, которые могут быть использованы для улучшения оптимизации, например, встраивать ли вызов конкретного метода.

HotSpot поставляется с двумя компиляторами: клиентским и серверным. По умолчанию используется клиентский компилятор. Вы можете выбрать серверный компилятор, указав параметр -server при запуске JVM. Серверный компилятор оптимизирован для повышения пиковой скорости работы и предназначен для "долгоиграющих" серверных приложений. Клиентский компилятор оптимизирован для уменьшения времени начального запуска приложения и занимаемого объема памяти, реализует менее сложную оптимизацию, чем серверный компилятор, и, следовательно, требует меньше времени для компиляции.

Серверный компилятор HotSpot может выполнять впечатляющее число видов оптимизации. Среди них множество стандартных видов оптимизации, имеющихся в статических компиляторах, например, выведение кода из тела циклов, общее удаление подвыражения, развертка цикла, удаление проверки диапазона, удаление "мертвого" кода, анализ движения данных, а также множество оптимизаций, обычно не применяющихся в статических компиляторах, например, принудительное встраивание вызовов виртуальных методов.

Непрерывная перекомпиляция

Еще одна интересная особенность HotSpot - компиляция не осуществляется по принципу "все или ничего". Code path (байт-код) компилируется в машинный код после интерпретации его определенное количество раз. Но JVM продолжает анализ и может перекомпилировать код заново с более высоким уровнем оптимизации, если решит, что code path является особенно "горячим" или последующий анализ данных показал возможность дополнительной оптимизации. JVM может перекомпилировать одни и те же байт-коды много раз при выполнении одиночного приложения. Для получения более подробной информации о работе компилятора попробуйте вызвать JVM с флагом -XX:+PrintCompilation, который заставляет компилятор (клиентский или серверный) каждый раз во время своей работы выводить на экран короткое сообщение.

Замещение в стеке

Первая версия HotSpot выполняла компиляцию по одному методу в каждый момент времени. Метод считался "горячим", если он выполнял итерации цикла, превышающие определенное количество раз (10000 в первой версии HotSpot, на данный момент - 2000). Это определялось назначением каждому методу счетчика и увеличением его значения каждый раз при выполнении обратного перехода. Однако после компиляции метода переключение на компилированную версию не производилось до тех пор, пока не происходил выход из метода и повторный вход - компилированная версия могла использоваться только для последовательных вызовов. В результате этого в некоторых ситуациях компилированная версия вообще никогда не использовалась, например, в случае программы, выполняющей интенсивные вычисления и в которой все вычисления производятся одинарным вызовом метода. В такой ситуации вычисляющий метод может быть скомпилирован, но компилированный код ни разу не использоваться.

Более свежие версии HotSpot используют технологию, называемую on-stack replacement (OSR), для разрешения переключения от интерпретируемого кода к компилированному (или замены одной версии компилированного кода другой) в середине цикла.

Дата добавления: 2015-10-29