Phantom Operating System

Рассказ об этом проекте The Register начинает традиционным для импортных статей о русских программистах образом. В Москве девять градусов по Фаренгейту, вследствие чего абориген Dmitry Zavalishin вынужден сидеть дома и отлаживать код операционной системы Phantom. Другого способа абстрагироваться от ужасной погоды у Dmitry Zavalishin нету.


Можно иронизировать по поводу опубликованного англичанами текста, однако нельзя не признать, что именно после него (а также заметки о Phantom на slashdot.org) проект получил известность на родине разработчика. Из-за тона онлайн-обсуждений на русском языке (например, здесь) известность эту впору назвать скандальной.

Начало переписки с Дмитрием и нас заставило подумать, что он – городской сумасшедший. Судите сами. Человек утверждает, что может создать ОС, обеспечивающую рост производительности труда программиста на 200-400%.

Предупреждение читателю

Дальнейший текст представляет собой краткое и более или менее добросовестное изложение беседы с Дмитрием Завалишиным, разработчиком операционной системы Phantom.

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

Задачу эту выполнить не удалось, несмотря на все старания. Даже примитивное описание Phantom’а представляет собой весьма непростое чтение. Если такое вам не по вкусу, бросьте читать прямо здесь.

Кому она нужна

Вы полагаете, будто операционная система (представьте себе для наглядности Windows) нужна пользователям, т.е. нам с вами? Да, но только во вторую очередь. В первую – операционная система нужна программистам.

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

Но самый главный ресурс, который ОС должна позволять использовать как можно более эффективно – это время программиста. Поэтому скорость разработки приложений есть главный критерий качества ОС. Если разрабатывать приложения для какой-то ОС неудобно, она плоха.

Современные ОС – старые ОС

Эволюция языков программирования позволила радикально ускорить отладку отдельно взятого приложения: современный программист легко справляется со множеством взаимосвязанных объектов весьма сложной структуры. Но как только требуется передать эти объекты из одного приложения в другое, программирование становится, по словам Дмитрия Завалишина, "смертоносно сложным".

Пример – технология OLE, существующая в Windows с незапамятных времен. С ее помощью можно внедрить, например, полноценную таблицу Excel в документ Word. Для пользователя OLE – великое благо. Но приложений, реализующих OLE, ничтожно мало по причине запредельной трудоемкости изготовления кода. Да и иные способы взаимодействия программ – не легче. Все многообразие объектов, связанных друг с другом в сложный граф, надо свернуть в линейную последовательность байтов, чтобы передать другому приложению, которое, в свою очередь, станет восстанавливать данные во всем многообразии их структуры из примитивной, не приспособленной ни для чего сложного линейной последовательности.

Все хорошо, пока мы пишем приложения. Но как только нам надо выйти на уровень операционной системы для того, чтобы обеспечить их взаимодействие – мы оказываемся в далеком прошлом, среди технологий полувековой давности.

Почему так

Потому что каждое приложение (точнее, процесс) в современных ОС (а все они в той или иной степени UNIX-подобны; правильно будет сказать, что мы все еще живем в эпоху UNIX) работает в своем адресном пространстве – выгороженном участке оперативной памяти, недоступном для других процессов. Иначе нельзя. Иначе процессы – по  злой ли воле или случайно – станут портить друг другу жизнь.

Разделение адресных пространств неэффективно с точки зрения использования ресурсов компьютера (обосновывающие объяснения придется опустить). Но оно гарантирует работоспособность, бесконфликтность одновременно работающих процессов.

Современный разработчик иного и не мыслит.

Intel 432

Но разделение адресных пространств вовсе не необходимо. Есть иные способы защитить процессы друг от друга.

Во времена, когда Intel сделала 286-й процессор (а было это более 20 лет назад – уже выросло поколение, которое такого и не помнит), был спроектирован чип Intel 432, который реализовывал красивейшую концепцию: не позволял преобразовать число в указатель на определенную область памяти. Просто не было такой операции. Указатель мог быть порожден только из указателя.

Такое простое решение позволяло обезопасить данные от случайного разрушения: если один процесс отдал указатель другому, тот мог обратиться к "чужой" памяти, а если нет – то и нет. Обратиться к произвольному фрагменту памяти в таком процессоре невозможно, а значит – все защищены друг от друга. Но – в отличие от нынешней ситуации – все процессы могут друг с другом взаимодействовать буквально напрямую, при наличии у них такого желания.

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

Без файлов

Описанные трудности преобразования сложно организованных объектов в линейную последовательность байтов возникают, между прочим, и при вводе-выводе данных. Документ Word, представляющий собой, простите за бесконечное повторение, сложную совокупность взаимосвязанных объектов, при выводе в файл вытягивается в одномерную цепочку нулей и единиц.

Но зачем это нужно? Если адресное пространство едино, достаточно просто наладить механизм его эффективного сохранения в энергонезависимой памяти (на диске). Да, это чрезвычайно затратное дело – вспомните о функции Hibernate в Windows. Минуты уходят на то, чтобы записать всю оперативную память на диск, причем не всегда потом удается восстановить систему в зафиксированном состоянии.

Но процедуры вроде Hibernate и не требуется. Все современные ОС в ходе работы используют т.н. виртуальную память, рассматривая ее на логическом уровне как продолжение оперативной, в то время как физически она лежит на диске (на сей счет устоялась терминология: swapping, paging). Это работает в реальном времени, одновременно с приложениями.

Есть, однако, очевидная проблема. В том случае, если одновременно с работой приложений надо зафиксировать ("сфотографировать") на диск актуальное состояние постоянно модифицируемой оперативной памяти, ее, эту память, нельзя выгружать по кусочкам. Она нужна нам целиком. Иначе потом систему не поднимешь после, например, аварийного выключения питания.

Но останавливаться и ждать, пока ОС довершит фиксацию (получится тот же Hibernate), нет времени.

Дмитрий Завалишин утверждает, что решил эту проблему. Phantom время от времени "поднимает волну", которая бежит по памяти, выводя ее содержимое на диск. Процессы при этом вправе модифицировать память только в той ее части, которая еще не выгружена, не зафиксирована на диске. Если же им потребовалась модификация ещё не выгруженной памяти, соответствующий фрагмент памяти обрабатывается по специальной процедуре и переносится "вперёд", за гребень волны. Быстрые алгоритмы для такой процедуры вполне могут быть реализованы. Пользователь ничего не почувствует.

Это означает почти полный отказ от понятия "файл" в его нынешнем понимании. Точнее сказать – использование файлов перестаёт быть неизбежной повинностью программиста.

Почему теперь

Т.н. технология бинарной трансляции, ныне широко применяемая в системах виртуализации, позволяет сделать из любого реального компьютера любой виртуальный. Причем с очень высокой эффективностью. Пример – компания Transmeta (в которой трудился, кстати говоря, Линус Торвальдс). Ее процессор ничего общего с архитектурой 8086 не имел, однако работал под Windows благодаря системам бинарной трансляции – прикладной софт не замечал подмены.

Выбрасывать старые приложения в связи с приходом новой гипотетической ОС – Phantom, как вариант – скорее всего, не придется. Двухшаговая трансляция с промежуточным представлением программного кода в форме эсперанто (т.н. bytecode), "понятного" для транслятора, обеспечивающего эффективный загрузочный код для любого процессора – функция, реализованная в большинстве современных языков программирования. C# и Java построены ровно так. Текст на C# компилируется в bytecode, который потом обрабатывается платформой .NET. Точно так же поступает с bytecode, полученным на первом шаге трансляции кода Java, виртуальная Java-машина.

Все это развязывает руки разработчику операционных систем. Время принципиально новых решений в области проектирования ОС наступает или уже наступило. Причем новая ОС не будет революцией. Ее приход для пользователя станет потрясением несколько меньшим по сравнению с тем, которое сопровождало выход Windows 95. Он, пользователь, уже подготовлен к переменам в этой области появлением новых ОС вроде Android.

Заключительное замечание

Многие важные детали опущены ради компактности изложения, что оставляет простор для уточняющих вопросов и критики.