Байт-код

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

В программировании, байт-код или байтко́д (англ. bytecode, иногда также используется термин псевдоко́д и p-code) — это промежуточное представление[en], в которое может быть переведена компьютерная программа. По сравнению с исходным кодом, удобным для создания и чтения человеком, байт-код — это компактное представление программы, уже прошедшей синтаксический и семантический анализ. В нём в явном виде закодированы типы, области видимости и т. п. С технической точки зрения, байт-код представляет собой машинно-независимый код низкого уровня, генерируемый транслятором из исходного кода.

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

По форме байт-код похож на машинный код, но предназначен для исполнения не реальным процессором, а виртуальной машиной. В качестве виртуальной машины обычно выступает интерпретатор соответствующего языка программирования (иногда дополненный JIT- или AOT-компилятором). Спецификации байт-кода и исполняющих его виртуальных машин могут сильно различаться для разных языков: часто байт-код состоит из инструкций для стековой[en] виртуальной машины[1], однако могут использоваться и регистровые[en] машины[2][3]. Тем не менее, большинство инструкций байт-кода обычно эквивалентны одной или нескольким командам ассемблера.

Байт-код называется так, потому что длина каждого кода операции традиционно составляет один байт. Каждая инструкция обычно представляет собой однобайтовый код операции (от 0 до 255), за которым могут следовать различные параметры, например, номер регистра или адрес в памяти.

Исполнение[править | править вики-текст]

Программа на байт-коде обычно выполняется интерпретатором байт-кода. Преимущество байт-кода в большей эффективности и портируемости, то есть один и тот же байт-код может исполняться на разных платформах и архитектурах, для которых реализован интерпретатор. То же самое преимущество дают непосредственно интерпретируемые языки, однако, поскольку байт-код обычно менее абстрактен и более компактен, чем исходный код, эффективность интерпретации байт-кода обычно выше, чем чистая интерпретация исходного кода или интерпретация АСД. Кроме того, интерпретатор байт-кода зачастую проще интерпретатора исходного кода и его проще перенести (портировать) на другую аппаратную платформу.

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

В то же время возможно создание процессоров, для которых данный байт-код является непосредственно машинным кодом (такие экспериментальные процессоры создавались, например, для языков Java и Форт).

История[править | править вики-текст]

Среди первых систем, использовавших байт-код, были O-code для BCPL (1960-е), Smalltalk (1976)[4], SIL (System Implementation Language) для языка Snobol-4 (1967), p-код (p-code, 1970-е, при участии Никлауса Вирта) для переносимых компиляторов языка программирования Pascal[5][6][7].

Варианты p-кода широко использовались в различных реализациях языка Pascal, например, в UCSD p-System (UCSD Pascal).[8]

Примеры[править | править вики-текст]

К интерпретируемым языкам, использующим байт-код, относятся Perl, PHP (например Zend Engine), Ruby (начиная с версии 1.9), Python, Erlang и многие другие.

Чрезвычайно широко распространены платформы, использующие байт-коды[9]:

  • Байт-код Java (стековая виртуальная машина), исполняемый различными виртуальными машинами Java (англ. Java Virtual Machine, JVM)[10][11]. Платформа была создана компанией Sun для языка Java, но стала использоваться и для других языков; существуют десятки высокопроизводительных реализаций JVM, использующих JIT-компиляторы.
    • Существуют варианты трансляции Java в байт-код регистровых машин, например, в виртуальной машине Dalvik (с JIT компиляцией) или при AOT-компиляции в ART
  • Платформа Microsoft .NET использует стековый байт-код Intermediate Language (CIL, MSIL)[8], исполняемый с помощью Common Language Runtime (CLR). См. Управляемый код. Данная платформа была создана Microsoft для языков C# и других.
  • Скриптовый язык JavaScript выполняется различными высокопроизводительными движками, в основном, встроенными в веб-браузеры, часто с возможностью JIT-оптимизации. Многие движки построены с применением байт-кода, однако программы на Javascript распространяются в виде исходных кодов.
  • Скриптовый язык ActionScript транслируется в стековый байт-код, распространяется в составе swf и pdf файлов, и выполняется виртуальными машинами в Adobe Flash и Adobe Acrobat.

Компилятор Clipper создает исполняемый файл, в который включен байт-код, транслированный из исходного текста программы, и виртуальная машина, исполняющая этот байт-код.

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

В ранних реализациях Visual Basic (до версии 6) использовался высокоуровневый p-code[9]

Высокоуровневые P-коды и байт коды применялись в СУБД, некоторых реализациях BASIC и Паскаля.

В стандарте открытых загрузчиков Open Firmware фирмы Sun Microsystems байт-код представляет операторы языка Forth.

Критика[править | править вики-текст]

Традиционно байт-код проектируется в стиле стековых виртуальных машин, что упрощает генерацию из AST, позволяет использовать более простую и компактную кодировку байт-кода, упростить интерпретатор и уменьшить количество машинного кода, требуемого для исполнения одной инструкции байт-кода. С другой стороны, такие варианты байт-кода для заданной программы содержат большее количество инструкций, чем байт-коды регистровых виртуальных машин, из-за чего интерпретатор должен совершить больше непрямых переходов, для которых плохо работает предсказание переходов[3]. Переход на регистровые виртуальные машины немного увеличивает общий размер байт-кода, однако уменьшает количество инструкций примерно вдвое и ускоряет интерпретатор на десятки процентов[3]. Также байт-код стековых машин сложнее для проведения оптимизаций (выражения становятся неявными, связанные инструкции не сгруппированы, выражения распределены по нескольким базовым блокам)[12] и требует верификации корректности использования стека[13].

Ошибки верификации байт-кода стековых машин приводили к появлению множества экстремально опасных уязвимостей, в частности десятков в виртуальной машине AVM2, используемой в Adobe Flash для исполнения скриптов ActionScript[14][15][16] и нескольких в ранних популярных системах исполнения Java (JVM)[17][18]

В конце 2000-х - начале 2010-х авторы компиляторов V8 (для языка JavaScript, часто реализуемого через байт-код)[19] и Dart[20] усомнились в том, что промежуточные байткоды обязательны для быстрых и эффективных виртуальных машин. В этих проектах была реализована непосредственная JIT-компляция (компиляция во время исполнения) из исходных кодов сразу в машинный код.[21]


Примечания[править | править вики-текст]

  1. Terence Parr. Language Implementation Patterns — Pragmatic Bookshelf, December 2009, ISBN 978-1-934356-45-6 «Part 3: Building Interpreters. Pattern 27 Stack-Based Bytecode Interpreter»
  2. Terence Parr. Language Implementation Patterns — Pragmatic Bookshelf, December 2009, ISBN 978-1-934356-45-6 «Part 3: Building Interpreters. Pattern 28 Register-Based Bytecode Interpreter»
  3. 1 2 3 Yunhe Shi, David Gregg, Andrew Beatty, M. Anton Ertl Virtual Machine Showdown: Stack Versus Registers (англ.) // VEE '05: Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments. — Chicago, Illinois, USA: ACM, 2005. — С. 153 - 163. — ISBN 1-59593-047-7. — DOI:10.1145/1064979.1065001
  4. Bringing Performanceand Scalability toDynamic Languages // Mario Wolczko, Oracle 2012 слайд 7
  5. Руслан Богатырев. Летопись языков Паскаль, Мир ПК, № 04/2001
  6. Компиляторы: принципы, технологии и инструментарий - Вильямс, ISBN 9785845901897, стр 517 "12.2 Компиляторы Pascal"
  7. THE UCSD P-SYSTEM MUSEUM, 2004
  8. 1 2 Understanding .NET: A Tutorial and Analysis, David Chappell, David Wayne Chappell, 2002, ISBN 9780201741629 page 92
  9. 1 2 C# Versus Java / Dr. Dobb's Journal February 2001
  10. http://www.javaworld.com/article/2077233/core-java/bytecode-basics.html 1996
  11. Алан Джок. Компиляторы, интерпретаторы и байт-код. «Computerworld Россия», № 06, 2001. Проверено 18 мая 2015.
  12. Ando Saabas, Tarmo Uustalu Type systems for optimizing stack-based code // Electronic Notes in Theoretical Computer Science. — 2007. — В. 190.1. — С. 103-119.. — DOI:10.1016/j.entcs.2007.02.063: "virtual stack or virtual register VMs can be executed more efficiently using an interpreter. Virtual register machines can be an attractive alternative to stack architectures because they allow the number of executed VM instructions to be substantially reduced."
  13. Gerwin Klein and Martin Wildmoser, Verified Bytecode Subroutines // Journal of Automated Reasoning 30.3-4 (2003): 363-398. "Bytecode verification is a static check for bytecode safety. Its purpose is to ensure that the JVM only executes safe code: no operand stack over- or underflows, no ill-formed instructions, no type errors"
  14. Mark Dowd (X-Force Researcher IBM Internet Security Systems), Leveraging the ActionScript Virtual Machine, IBM 2008 "if there was a way to execute AS3 instructions that had never been verified, it would be quite dangerous. Unverified instructions would be able to manipulate the native runtime stack ... The attack works by manipulating a data structure used by the AVM2 verifier such that it doesn’t correctly verify the ActionScript instructions for a given method"
  15. Haifei Li, Understanding and Exploiting Flash ActionScript Vulnerabilities, 2011 "Bytecode -> Verification process ... ActionScript Vulnerabilities are due to various program flow calculating errors in the Verification/Generation Process (the Verification Flow and the Execution Flow are not the same)"
  16. Haifei Li (Microsoft), Inside AVM // REcon 2012, Montreal "Most Flash vulnerabilities are ActionScript-related ... Faults on verification cause highly-dangerous JIT type confusion vulnerabilities. • highly-dangerous means perfect exploitation: bypassing ASLR+DEP, with %100 reliability, no heapSpray, no JITSpray. • JIT type confusion bugs are due to faults in the verification of AVM!"
  17. The last stage of delirium research group, Java and Java Virtual Machine security vulnerabilities and their exploitation techniques, BlackHat 2002: "The flaw stemmed from the fact that Bytecode Verifier did not properly perform the bytecode flow analysis"
  18. Verification of Bytecode in a Virtual machine // International Journal of Advanced Research in Computer Science and Software Engineering Vol.3 Issue 3 March 2013, ISSN 2277-128X: "Java byte code verification has been studied extensively from a correctness perspective, and several vulnerabilities have been found and eliminated in this process"
  19. Dynamic Machine Code Generation. Google.
  20. Loitsch, Florian Why Not a Bytecode VM?. Google.
  21. JavaScript myth: JavaScript needs a standard bytecode.