Мы часто принимаем карту за территорию. Когда мы пишем программное обеспечение, мы общаемся на языке исходного кода — Python, Java, C++ — и строим ментальные модели машины, которая исполнит нашу волю. Мы представляем себе процессор, выбирающий инструкции, память, которая выделяется и освобождается, регистры, перетасовывающие данные. Это удобная иллюзия, полезный вымысел. Для значительной части программ, с которыми мы взаимодействуем ежедневно, эта машина, физическая кремниевая основа, не является той, что выполняет работу. Она всего лишь хост для другой, более абстрактной машины, призрака в кремниевой оболочке.
Наиболее успешным и повсеместным из таких призраков является Виртуальная машина Java (Java Virtual Machine, JVM). Говорить о ней как всего лишь об «инструменте» или «платформе» — значит упускать из виду profoundный эпистемологический сдвиг, который она представляет. JVM — это тщательно спроектированная реальность, последовательная и предсказуемая вселенная вычислений, существующая в слое абстракции над хаотичным, зависящим от вендора и невероятно разнообразным миром физического оборудования. Ее история — это не просто рассказ о технологическом достижении, но поучительный пример силы, заключенной в определении четкого, формального интерфейса, и emergentной сложности, которая может на нем расцвести. Понять JVM — значит понять фундаментальную стратегию укрощения сложности через посредничество и спецификацию.
Изначальная проблема, для решения которой создавалась JVM, сегодня стала исторической деталью, но в свое время она была formidable: «Написано один раз, работает везде» (Write Once, Run Anywhere). В середине 1990-х годов ландшафт вычислительной техники представлял собой цифровой Вавилон. Программное обеспечение, написанное для ПК с Windows на процессоре Intel x86, не работало на Mac с чипом PowerPC или на рабочей станции Sun с процессором SPARC. Самые инструкции, которые понимали эти процессоры, были разными. Перенос программного обеспечения был трудоемким, чреватым ошибками процессом переписывания и перекомпиляции. Команда Java, в порыве архитектурного гения, решила обойти проблему целиком. Вместо компиляции своего языка Java в native-машинный код для какого-то конкретного процессора, они стали компилировать его в машинный код для вымышленного, идеализированного процессора — Виртуальной машины Java.
Эта виртуальная машина не была физическим устройством. Это была спецификация, набор правил. Она определяла свой собственный набор инструкций, известный как байт-код (bytecode), свою собственную модель памяти для кучи (heap) и стека (stack), а также свои собственные протоколы безопасности и выполнения. Реальный, физический компьютер должен был запускать программу — саму реализацию JVM, — которая эмулировала бы этот вымышленный процессор. Ваша Java-программа, скомпилированная в байт-код, была сценарием для этого эмулятора. Эмулятор, написанный на нативном коде для Windows, Mac или Linux, в свою очередь, транслировал этот сценарий из байт-кода в фактические, нативные инструкции хостовой машины. Территория — это физический CPU; карта — это спецификация JVM; а Java-программа жила и умирала внутри карты.
Непосредственной выгодой была портативность. Вы могли взять .jar-файл с байт-кодом, и, при условии существования JVM для вашей операционной системы и архитектуры, он запускался. Это было революционное обещание. Но поистине захватывающие последствия заключались в emergentных свойствах, которые породила эта многоуровневая архитектура. Разместив виртуальную машину между программой и железом, разработчики JVM создали контролируемую среду, изолированную песочницу (sandbox), где они могли применять правила, невозможные на аппаратном уровне. Они смогли построить модель безопасности, «песочницу», которая ограничивала возможности байт-кода, делая безопасным запуск непроверенного кода из ранней веб-сети (обещание, чьи сложности — тема для отдельного эссе). Они могли автоматически управлять памятью с помощью Сборщика мусора (Garbage Collector, GC), освобождая программиста от утомительной и опасной задачи ручного управления памятью, которая преследовала языки вроде C и C++.
Пожалуй, самым значительным emergentным свойством стал Компилятор в реальном времени (Just-In-Time, JIT компилятор). Первые реализации JVM были интерпретаторами. Они читали каждую инструкцию байт-кода по одной и выполняли соответствующий ей участок нативного кода. Это было просто, но медленно, производительность часто была на порядок хуже, чем у нативного кода. JIT-компилятор стал блестящей оптимизацией, превратившей слабость в силу. Он наблюдал за кодом по мере его выполнения. Он идентифицировал «критические участки» (hot spots) — методы или циклы, которые выполнялись тысячи или миллионы раз. Затем, пока программа все еще работала, он компилировал эти участки из промежуточного байт-кода прямо в высокооптимизированный нативный машинный код. В следующий раз, когда исполнение доходило до этого пути, код выполнялся на нативной скорости.
Это profoundная идея. Статический, компилирующий заранее (ahead-of-time) компилятор, такой как GCC или Clang, вынужден делать консервативные предположения. Он не знает, какие пути выполнения будут «горячими» во время работы. JIT-компилятор, однако, имеет доступ к информации времени выполнения. Он знает фактические типы данных, протекающие через программу, он видит, какие виртуальные вызовы методов почти всегда обращаются к одному и тому же конкретному классу (что позволяет провести «девиртуализацию», devirtualization), и может выполнять агрессивное встраивание (inlining). Со временем JIT-компиляторы, такие как в HotSpot JVM от Oracle, стали невероятно сложными, по производительности в некоторых специфических, долгоиграющих серверных задачах сравнявшись, а иногда и превзойдя статически скомпилированный C++. Виртуальная машина, добавив уровень абстракции, не просто решила проблему портативности; она создала петлю обратной связи между выполнением и оптимизацией, ранее невозможную.
Таким образом, JVM — это не просто среда выполнения для языка Java. Это цель. Это вычислительная вселенная со своими собственными законами физики. И как только эта вселенная была определена и стабилизирована, люди начали исследовать, что еще может в ней существовать. Это привело к появлению полиглотной JVM. Разработчики осознали, что любой язык, который можно транслировать в байт-код JVM, может унаследовать все преимущества этой зрелой, высокопроизводительной, портативной платформы. И они пришли. Scala, со своими продвинутыми возможностями функционального программирования и системы типов. Clojure, лисп, embracing неизменяемость (immutability) и примитивы многопоточности JVM. Kotlin, современный язык, предлагающий лаконичность и безопасность при сохранении бесшовной интероперабельности с существующими Java-библиотеками. Groovy, JRuby, Jython — список длинен.
Эта полиглотная экосистема — мощное свидетельство ценности хорошо определенного интерфейса. Байт-код JVM и фундаментальные Java-классы образуют общую лингва франка. Библиотека, написанная на Java, может быть бесшовно вызвана из Scala. Сложная структура данных из Clojure может быть передана в функцию на Kotlin. Все они компилируются в один и тот же байт-код и работают в рамках одной модели памяти. Эта интероперабельность — огромный усилитель. Это означает, что колоссальные инвестиции в Java-библиотеки на протяжении десятилетий — для всего, от веб-сервисов до научных вычислений, — не заперты в языке Java. Новый язык на JVM рождается уже с богатой, зрелой экосистемой. JVM становится видом-ключевым камнем (keystone species) в процветающей программной экосистеме, ее стабильность позволяет радикальное разнообразие и эксперименты на языковом уровне.
Конечно, JVM — не единственная абстрактная машина, имеющая значение. Общеязыковая среда выполнения .NET (Common Language Runtime, CLR), разработанная Microsoft, является ее прямым духовным и техническим конкурентом. CLR следует практически идентичному архитектурному плану. Она определяет Общий промежуточный язык (Common Intermediate Language, CIL, ранее MSIL), Общую систему типов (Common Type System, CTS) и предоставляет такие услуги, как сборка мусора и JIT-компилятор. Основное историческое различие заключалось в философии и домене; JVM родилась из овеянного солнцем, кроссплатформенного обещания ранней веб-эпохи, в то время как CLR изначально была тесно интегрирована с операционной системой Windows. Это различие значительно стерлось с открытием исходного кода .NET и его кроссплатформенной реализацией, .NET Core. CLR также поддерживает полиглотную экосистему, наиболее prominentными гражданами которой являются C#, F# и Visual Basic .NET.
Архитектурное сходство между JVM и CLR не является случайностью. Оно представляет собой локальный оптимум в пространстве проектирования управляемых сред выполнения. Обе сошлись на модели, которая включает стековое промежуточное представление (stack-based intermediate representation), управляемую сборщиком мусора кучу (garbage-collected heap), JIT-компиляцию с многоуровневой оптимизацией и всеобъемлющую базовую библиотеку классов (base class library). Эта конвергенция предполагает, что для широкого класса задач общего назначения высокоуровневого программирования это чрезвычайно эффективная модель. Она балансирует производительность, безопасность и продуктивность разработчика так, как чисто интерпретируемые или чисто статически компилируемые модели часто сделать не в состоянии.
Более новый и глубоко важный претендент в этом пространстве — Виртуальная машина WebAssembly (WASM). Изначально задуманная как безопасная, быстрая, портативная цель компиляции для веба — позволяющая таким языкам, как C++ и Rust, работать в браузерах с скоростью, близкой к нативной, — ее амбиции быстро расширились до серверов и периферии (edge). WASM определяет компактный бинарный формат инструкций для стековой виртуальной машины. Она спроектирована так, чтобы быть по построению безопасной (memory-safe) и изолированной, с возможностями (capabilities), которые должны быть явно предоставлены хост-средой.
WASM представляет собой захватывающую эволюцию концепции абстрактной машины. Она, в некотором смысле, минималистичная и более об
