Spring — это прекращенный проект по созданию экспериментальной объектно-ориентированной операционной системы (ОС) на основе микроядра , разработанной в Sun Microsystems в начале 1990-х годов. Используя технологию, по существу аналогичную концепциям, разработанным в ядре Mach , Spring сосредоточился на предоставлении более богатой среды программирования, поддерживающей множественное наследование и другие функции. Spring также был более четко отделен от операционных систем, которые он размещал, отделив его от корней Unix и даже позволяя запускать несколько ОС одновременно. Разработка сошла на нет в середине 1990-х годов, но несколько идей и некоторый код проекта позже были повторно использованы в библиотеках языка программирования Java и операционной системе Solaris .
Spring начался окольным путем в 1987 году как часть сотрудничества Sun и AT&T по созданию объединенной UNIX . Обе компании решили, что это также хорошая возможность «переопределить UNIX объектно-ориентированным способом». [2] Однако после нескольких встреч эта часть проекта умерла.
Сан решила сохранить свою команду и вместо этого исследовать передовую систему. Помимо сочетания разновидностей Unix, новая система также сможет запускать практически любую другую систему, причем распределенным образом . Впервые система была запущена в «полном» виде в 1993 году и подготовила серию исследовательских работ. В 1994 году была выпущена версия «исследовательского качества» по некоммерческой лицензии, но неясно, насколько широко она использовалась. Программное обеспечение, описанное как «чистый лист», призванное помочь Sun улучшить существующие продукты Unix, было доступно по цене 75 долларов, при этом Sun ориентировалась на университеты и ученых-компьютерщиков. [3] Коммерческие исследовательские учреждения могут получить программное обеспечение по цене 750 долларов. [4] Команда распалась и перешла к другим проектам внутри Sun, используя некоторые концепции Spring в ряде других проектов.
Проект Spring начался вскоре после выпуска Mach 3. В более ранних версиях Mach был просто модифицированной версией существующих ядер BSD , но в Mach 3 службы Unix были выделены и запускались как программа пользовательского пространства, как и любая другая, концепция Мах называется сервером . Данные, которые обычно были конфиденциальными в ядре в традиционной системе Unix, теперь передавались между серверами и пользовательскими программами с использованием системы межпроцессного взаимодействия (IPC), заканчиваясь портами , которые принадлежали обеим программам. Мах реализовал эти порты в ядре, используя виртуальную память для перемещения данных из программы в программу, полагаясь на блок управления памятью (MMU) и алгоритм копирования при записи, чтобы сделать это с разумной производительностью.
В конечном итоге операционная система на Маха будет состоять из нескольких таких серверов, каждый из которых будет выполнять определенную задачу. Примеры могут включать файловую систему или сетевой стек . Сервер операционной системы в такой системе будет довольно небольшим, предоставляя услуги, уникальные для этой ОС, и перенаправляя большинство других вызовов на другие серверы. Поскольку ОС работала поверх одного набора общих серверов, одновременно можно было запускать несколько серверов ОС, что позволяло одной системе «врожденно» поддерживать DOS , Unix и другие операционные системы одновременно.
Эта возможность была особенно интересна таким компаниям, как IBM , которые уже поддерживали несколько различных систем и видели в Mach способ объединить их с общим базовым кодом. На самом деле это было не так-то просто. Мах принял несколько решений на низком уровне, которые сделали любую систему, работающую на нем, в некоторой степени похожей на Unix. Наиболее примечательной была система безопасности, построенная по довольно негибкой унаследованной модели программ Unix. Кроме того, система IPC оказалась серьезной проблемой с производительностью, хотя природа этой проблемы стала ясна лишь позже. Производительность была настолько низкой, что многие коммерческие проекты по портированию существующих операционных систем на Mach, в частности IBM Workplace OS , в конечном итоге были заброшены.
Хотя Sun также была заинтересована в поддержке нескольких операционных систем, их потребности не были такими острыми, как у IBM или Apple. К этому моменту они уже перенесли платформы со своих ранних машин на базе 68k на линейку SPARC , а их операционная система Solaris на базе UNIX System V заменила их SunOS на базе BSD. Обеспокоенность Sun была несколько более тонкой: поддерживать интерес разработчиков к версии Unix от Sun; и позволяя их системе масштабироваться на более мелкие устройства, такие как телеприставки . Система на основе микроядра была бы особенно полезна в этой последней роли.
Spring сконцентрировался на «программируемости»; что упрощает разработку системы. Основным дополнением в этом отношении была разработка языка определения интерфейсов (IDL), который экспортировал интерфейсы со значительно большим количеством информации, чем тот, который использовался в Mach. Помимо функций и их параметров, интерфейсы Spring также включают информацию о том, какие ошибки могут возникать и к какому пространству имен они принадлежат. При наличии подходящего языка программы, включая серверы операционной системы, могли импортировать несколько интерфейсов и комбинировать их, как если бы они были объектами, родными для этого языка — особенно C++ . Некоторое время спустя Spring IDL был принят с небольшими изменениями как CORBA IDL .
Spring также исследовал ряд конкретных усовершенствований программного обеспечения в области файловых систем, виртуальной памяти и производительности IPC. В результате получилась единая Unix-подобная система с гораздо большей производительностью, чем у Mach. Некоторые из этих изменений подробно описаны ниже.
Инженеры Sun использовали нестандартную терминологию для обозначения ряда общих компонентов, что делает обсуждение системы несколько запутанным. Например, задачи Маха называются доменами , порты — дверями , а ядро — ядром . [5]
Ядро Spring было разделено на две части: систему виртуальной памяти и ядро . Хотя ядро эквивалентно только одной части ядра Маха, ядра каждой ОС достаточно аналогичны, чтобы можно было считать, что они выполняют одну и ту же функцию.
Ядро Spring включает в себя только самые базовые функции и состояния, необходимые для поддержки пользовательских приложений. В первую очередь это включает в себя состояние для ведения списков запущенных программ ( доменов ) и их потоков, а также каналов связи между ними ( дверей ).
Ядро Spring не является многопоточным. Обычно это исключает возможность использования его в настройках реального времени , но неясно, в этом ли дело. Обычно ядра должны быть многопоточными, чтобы гарантировать, что длительная задача, такая как дисковый ввод-вывод, не будет загружать систему и не препятствовать своевременному обслуживанию последующего вызова; в Spring ядро почти сразу же передает подавляющее большинство запросов на серверы, поэтому в соответствии с этой моделью теоретически должны быть подключены только серверы.
Одним из основных различий между Mach и Spring была система IPC. В Mach система была организована как набор односторонних асинхронных каналов ( портов ) между программами — концепция, заимствованная из каналов Unix . Однако в программировании наиболее распространенным методом связи является вызов процедуры или вызов/возврат, который Мах напрямую не поддерживал. Семантика вызова/возврата может поддерживаться только с помощью дополнительного кода в библиотеках более высокого уровня, основанного на базовом механизме портов, что увеличивает сложность.
Вместо этого Spring напрямую поддерживал семантику вызова/возврата в базовой системе связи. Это привело к изменению терминологии с портов в Mach на двери в Spring. Двери были известны только ядру; программам была передана «ручка» двери с идентификатором, который был уникальным для этой программы. Система работала аналогично портам для исходного сообщения; Сообщения, отправленные на дверь, проверялись ядром, чтобы найти целевое приложение и перевести дверную ручку, но затем ядро записывало небольшие объемы информации от вызывающего абонента, чтобы иметь возможность быстро возвращать данные. Это ускорило возврат примерно на 40%.
Кроме того, модель Маха была асинхронной — вызов возвращался, если и когда на сервере были данные. Это соответствовало исходной модели каналов Unix, которая позволяла запускать другие программы, если сервер был занят. Однако для системы вызова/возврата это имеет серьезные недостатки, поскольку планировщик задач должен запускаться для выбора следующей программы для обслуживания. Будем надеяться, что это был сервер, с которого вызов запрашивал данные, но это не было гарантировано. В Spring IPC синхронен; управление немедленно передается серверу без запуска планировщика, что сокращает время прохождения туда и обратно в обычном случае, когда сервер может немедленно вернуться.
При Маха система виртуальной памяти , поддерживаемая блоком управления памятью (MMU), должна была обеспечить легкое решение для копирования данных путем простого сопоставления одних и тех же данных в памяти с двумя программами. На самом деле это решение было совсем неэффективным, поскольку многие MMU имели конструктивные особенности, которые делали это отображение медленным или даже невозможным.
В отличие от универсального решения Маха для IPC, Spring использовал множество методов для физической передачи данных между программами. Один из них, Bulk-path , по сути был идентичен портам и сообщениям Маха, но на практике Bulk-path был наименее распространенным типом сообщений. Для небольших сообщений Spring предоставил vanilla-path , который напрямую копировал данные из одного пространства в другое, что оказалось быстрее, чем отображение памяти в реальном мире для менее 5 КБ данных.
Быстрый путь позволял выполнять чрезвычайно быстрые вызовы — по крайней мере, при работе на платформах на базе SPARC . В быстром пути использовалась уникальная «полуловушка», позволяющая избежать большей части накладных расходов на переключение контекста , от которых страдали системы Маха. Вместо сохранения всего состояния процессора (обычная процедура в случае ловушки ядра) Spring сохранил только 16 верхних регистров SPARC, число, которое определялось конкретными деталями реализации архитектуры SPARC. Остальные части стека регистров были сделаны невидимыми для получателя с помощью инструкции SPARC WIM, обеспечивая некоторый уровень безопасности. Быстрый путь сильно напоминает классический вызов процедуры внутри одного приложения, которое использует окна регистров в SPARC, добавляя некоторую работу MMU для перемещения контекста из одной программы в другую.
Быстрый путь был доступен только для вызовов, передающих простые значения, которые не нужно было переводить (например, без ссылок на двери), всего до 16 значений. Хотя это может показаться весьма ограниченным, на самом деле быстрый путь используется подавляющим большинством вызовов Spring — обычно более 80% вызовов и около 60% возвратов. Возвраты часто отвечают большими блоками данных, например, дисковым блоком, что объясняет, почему в возвратах чаще использовались другие системы IPC.
В 32-битных системах SPARC V8 полный вызов туда и обратно с использованием быстрого пути требовал чуть более 100 инструкций, что делало его во много раз быстрее, чем обычный вызов Mach. Остается неясным, можно ли реализовать быстрый путь на других машинах, поэтому общее улучшение производительности Spring трудно сравнивать с Mach, которое обычно измерялось на системах IA-32 . В частности, полный системный вызов занимал менее 20 мкс на 486DX-50 для существующих систем BSD Unix и 114 мкс под Mach. Это привело к падению производительности на 50% и более и обрекло большинство проектов Mach на провал. Напротив, Spring, использующий быстрый путь, мог похвастаться временем IPC всего 11 мкс на SPARCstation 2 .
Еще одной ключевой областью улучшений в Spring стала реализация системы виртуальной памяти (VM), которая также является частью ядра. Виртуальная память — это система, которая связывает воедино физическую оперативную память (ОЗУ) в машине, MMU и дисковую систему, чтобы создать иллюзию, что каждая программа в системе имеет свой собственный блок ОЗУ, равный максимальному размеру машины. и операционная система может поддерживать. Наиболее распространенной моделью адресации памяти в компьютерах и операционных системах, использовавшихся в 1980-х и 1990-х годах, была 32-битная модель, обеспечивающая доступ к теоретическому пределу памяти в 4 ГиБ , но до начала 2000-х годов только относительно дорогие компьютеры могли иметь столько памяти. физическая оперативная память. Система VM создает иллюзию большего, используя жесткий диск в качестве резервного хранилища — области гораздо более медленной памяти, используемой для разгрузки неактивных частей ОЗУ.
В традиционных системах Unix виртуальная машина является частью ядра, как и обработчики диска и памяти, которые она связывает вместе. При Mach решение о том, где разместить систему виртуальных машин, не так очевидно — хотя ядро управляет оперативной памятью и MMU, обработчики дисков являются частью внешних клиентских программ. Чтобы решить эту проблему, Mach 3 представил новую двухуровневую систему виртуальных машин с контролем фактической системы виртуальных машин в ядре, которая затем запрашивала внешний пейджер клиентского пространства для взаимодействия с дисковой системой для физического копирования памяти. К сожалению, это оказалось серьезной проблемой производительности, потребовавшей нескольких входов и выходов из ядра (с последующими переключениями контекста), когда различные уровни системы VM вызывали друг друга.
Преимущество команды Spring заключалось в том, что она могла изучить, что пошло не так с моделью Маха, и исправить это. Результатом стала гораздо более четко разделенная система адресных пространств в программах, отображаемая виртуальной машиной в различные объекты памяти , которые, в свою очередь, управлялись пейджером для поддержки обработки хранилища. Когда программа делала запрос данных, запрос передавался системе VM в ядре, которая находила соответствующий пейджер и просила его создать и настроить соответствующий объект памяти. Взамен пейджеру был передан диспетчер кэша от виртуальной машины, который отвечал за отслеживание состояния чистоты/грязности локального кэша этого объекта памяти. Детали реализации значительно усложнили эту модель, но большая часть этого была скрыта. В конце концов, в базовой системе были пейджеры, отвечающие за память, и адресные пространства, отвечающие за кэши. У них были четко определенные интерфейсы, позволяющие им передавать команды туда и обратно для синхронизации данных.
Такое разделение обязанностей привело к очень реальному улучшению производительности. Поскольку программы могут совместно использовать объекты памяти, а системы микроядра, такие как Spring, основаны на идее копирования памяти, Spring позволил программам, разделяющим память таким образом, также использовать ее в системе VM. Таким образом, под Mach, если сетевой файловый сервер передает данные программе, обе программы в конечном итоге будут использовать память в системе VM, тогда как под Spring они, естественно , будут использовать одни и те же объекты памяти, поскольку пейджер, реализующий этот объект памяти, просто вернет другой дескриптор той же памяти. Только внутри виртуальной машины они будут считаться разными объектами и обрабатываться отдельными менеджерами кэша. Следовательно, данные будут кэшироваться в оперативной памяти только один раз. Теоретически это может привести к значительному улучшению использования оперативной памяти в реальном мире.
Кроме того, использование внешних пейджеров с четко определенным API позволило четко отделить систему, когда это было необходимо. Spring также позволял самим программам указывать, какой пейджер лучше всего подходит для их нужд, включая их самих, что позволяло программам Spring легко реализовывать частные системы виртуальных машин для известных рабочих нагрузок. Для таких приложений, как файловые серверы , веб-серверы и системы управления базами данных , специальные виртуальные машины и файловые системы часто приводят к значительному повышению производительности.
Большинство операционных систем включают в себя различные службы именования . Самым простым примером является файловая система, в которой файлы внутренне ссылаются на «дескриптор», небольшое число, а отдельный каталог присваивает имена файлам, с которыми взаимодействуют пользователи. Такая же дихотомия имени/идентификатора встречается во многих других частях типичной системы Unix; принтеры именуются в etc/printcapфайле, небольшие числа и строки — в переменных среды, а сетевые расположения — в DNS. Каждая из этих систем предоставила свои собственные имена и собственный API , благодаря чему разные объекты выглядели совершенно разными даже в концепции.
Другие системы пытались добавить системы именования к существующим системам Unix, но обычно это были «прикрытия» существующих функций, которые просто собирали все имена из этих различных служб и представляли их в одной коллекции. Поскольку они полагались на знание базовой структуры системы, они имели тенденцию быть довольно негибкими, что затрудняло добавление новых сервисов. Кажется, от них мало пользы.
Только в совершенно новой операционной системе можно было надеяться на предоставление универсального сервиса. Например, Plan 9 использовал файловую систему в качестве универсальной службы имен; ко всему, от принтеров до окон, можно было получить доступ по имени через файловую систему. Это расширение исходной концепции Unix, которая постепенно исчезла по мере того, как с годами добавлялось все больше и больше функций.
У Mach не было какой-либо службы именования для своих портов. Это оказалось серьезной проблемой, поскольку программы должны были заранее знать, к каким серверам им нужно обращаться, чтобы попросить ядро предоставить порт. Это означало, что заменить функциональность оказалось гораздо сложнее, чем должно было быть; Например, новый сервер печати должен был использовать те же порты, что и старый: не было бы возможности запускать два одновременно для разработки. Если бы вместо этого порты назывались по имени, серверы могли бы находиться на разных портах и просто использовать одно и то же имя. Эта функциональность, предоставляемая сервером имен, считалась очень важной в Spring.
Подход Spring, по сути, перевернул систему Plan 9: в Spring файловая система была одним из примеров сервера, который использовал единую службу унифицированных имен. Тот же сервис можно использовать для именования файлов на диске, переменных среды, аппаратных устройств, программ и даже объектов внутри программ. Система была иерархической, systemнапрямую поддерживалось только пространство имен сервером, который запускался во время загрузки. Другие серверы затем «привязывали» известные им имена к системе, сервер печати создавал список принтеров, файловая система привязывала каталоги подключенных дисков. Таким образом, было построено отображение всех объектов в системе, возможно, во время выполнения, и доступ к ним можно было получить в виде файла, очень похожего на Plan 9. Доступ ко всем этим объектам можно было получить с помощью единого API, хотя система также предоставил множество библиотек-заглушек, чтобы они выглядели как классические службы, особенно на сервере эмуляции Unix.
Служба имен также была центральным местом обеспечения безопасности и разрешений. Поскольку двери, настоящие средства доступа в Spring, предоставлялись службой имен, сервер включал в себя полную систему проверки разрешений на основе списка контроля доступа . Таким образом, в дополнение к предоставлению разрешений для файловой системы, в Spring можно управлять любым объектом, используя тот же набор разрешений и пользовательский интерфейс. Сравните это, например, с Windows NT , которая включает около дюжины систем разрешений (файловая система, DCOM, доступ SQL, IIS и т. д.), каждую из которых необходимо настраивать отдельно. Чтобы повысить производительность, в систему включена концепция доверия, позволяющая серверам имен предполагать, что запросы от других серверов действительны. Например, если пользователь попросил файловый сервер получить доступ к файлу, системный сервер имен передаст запрос файловой системе, которая немедленно его обработает. Однако, поскольку пользователь неизвестен, ACL будут проверяться по файлу, к которому осуществляется доступ.
Группы родственных имен были известны как контексты . Контексты также были именами и, таким образом, аналогичны концепции каталога файловой системы. Пользователи могли создавать свои собственные контексты из, казалось бы, несвязанных объектов; принтеры, использующие совершенно отдельные драйверы (серверы), могут быть собраны в единый список, файл может иметь разные имена в разных местах (или для разных пользователей) или может быть создан единый домен, содержащий каждый личный файл в целях поиска. Таким образом, Spring позволил «объединить» файловые каталоги - полезную функцию, отсутствующую в традиционном Unixen.
В Spring не было встроенной системы сохранения объектов , но служба имен была постоянной и могла использоваться для поиска объектов таким способом. В некоторой степени ряд серверов, запущенных во время загрузки, обеспечивал постоянное пространство имен, которое выживало при загрузке, поскольку они копировали свои имена на один и тот же сервер. Теоретически система могла бы позволить серверу имен обеспечивать систему «отложенного запуска», не запуская сетевой сервер, например, до тех пор, пока кто-то не запросит его, но, похоже, эта функция не включена в нее. Фактически разделение пространств имен позволило бы передать эту функцию сервису, который фактически реализовал присвоение имен дверям, что значительно упростило реализацию.
Как говорилось ранее, виртуальная машина Spring позволяла любой программе определять, какой пейджер ей следует использовать. Кроме того, система Spring была основана на единой универсальной системе именования. Эти две концепции были объединены для создания файловой системы Spring.
Ключом к работе файловой системы Spring была тесная интеграция с системой VM. Поскольку было «известно», что система VM будет управлять локальным кэшем данных файловой системы, файловая система была сведена только к командной структуре и представляла собой собственный пейджер. То есть файловая система отвечала за загрузку и сохранение данных из объектов памяти, когда это необходимо, но кэширование этих данных выполнялось виртуальной машиной. Как упоминалось ранее, это означает, что в Spring файл существует в оперативной памяти только в одном месте, независимо от того, как он используется программами в системе.
Spring использовал два типа файловых систем: локальную файловую систему , похожую на большинство распространенных систем Unix, а также кэширующую файловую систему для сетевых устройств. Система кэширования демонстрирует полезность разделения виртуальной машины и пейджера Spring: она использует ту же физическую память виртуальной машины, которую ей пришлось бы использовать в обычном режиме, CFS закорачивает все запросы на чтение в локальный кеш и выполняет ленивую обратную запись каждые 30 минут. секунд в исходную файловую систему. Это было бы особенно заметно, если бы по сети загружались общие каталоги Unix, что является обычной процедурой для лабораторных рабочих станций . Большинство систем Unix используют аналогичные механизмы кэширования по тем же причинам производительности, но в конечном итоге оперативная память будет использоваться дважды: один раз в кеше, а затем в программах, использующих ее. CFS также кэшировала имена из удаленной системы, что значительно ускоряло первоначальный обход каталогов и открывание запросов.
Файловая система Spring также является поставщиком контекста службы имен, лениво сопоставляя каталоги из структуры на диске с новыми контекстами в службе имен. Затем к ним можно было получить доступ с помощью универсального API именования или, альтернативно, через библиотеку эмуляции Unix, которая представляла их как традиционную файловую систему Unix.
Обратите внимание, что использование термина « файловая система» в Spring несколько сбивает с толку. В обычном использовании этот термин относится к определенному способу физического хранения файлов на диске.
Spring также требовался для поддержки существующих приложений Unix, составляющих основу бизнеса Sun. Для этого Spring также поставляется с двумя ключевыми расширениями: сервером процессов Unix, который имитирует полную версию Unix, и переписанной стандартной библиотекой libc под названием libue , которая перенаправляет запросы ядра Unix на различные серверы. Например, приложение Unix, которому требуются файловые или сетевые службы, будет направлено на соответствующий сервер Spring, а приложение, которое хочет получить список запущенных в данный момент программ, будет направлено на сервер процессов Unix. Сервер процессов также отвечал за обработку сигналов — концепция, которая не имела аналога в Spring — и на самом деле она не была нужна, кроме как для обратной совместимости, поскольку сигналы, по сути, представляют собой негибкий одноцелевой механизм IPC.
Запуск приложения Unix под Spring требовал, чтобы оно было повторно связано с libue ; система поставлялась с большинством основных утилит Unix, а сервер X11 был повторно подключен и готов к использованию. Однако этот метод совместимости не был ни невидимым, ни гарантированно работающим; В документах Spring отмечается, что «многие» приложения будут работать без изменений (предположительно, кроме перекомпоновки), но не упоминается, какие проблемные области следует ожидать разработчику, если они этого не сделают.
Хотя это и не связано напрямую со Spring как таковым, инженеры Sun, работавшие над этим проектом, обнаружили, что существующие механизмы поддержки различных разновидностей вызовов не были четко определены. Чтобы обеспечить более богатый интерфейс, они разработали концепцию субподрядов .
Sun добавила в Solaris «унифицированную» версию Doors .
За годы, прошедшие после завершения работы над системой Spring, работа над операционными системами в целом по существу завершилась. Поскольку рынок быстро расслоился на мир, в котором доминируют Windows и Unix-подобные операционные системы, для любой другой системы, похоже, открыты только нишевые рынки. Кроме того, низкая скорость 3 Маха, похоже, выбила из колеи многие проекты.
Тем не менее, появились и более новые системы. В частности, микроядро L4 имеет много общего с ядром Spring. В частности, он также использует синхронную систему вызова/возврата для IPC и имеет аналогичную модель виртуальной машины. L4 до сих пор концентрировался почти исключительно на самом ядре; нет ничего аналогичного службе имен Spring, модели безопасности или файловой системе.