Spring (операционная система) - Spring (operating system)

Весна это прекращенный проект / экспериментальный микроядро -основан объектно-ориентированный Операционная система разработан в Sun Microsystems в начале 1990-х гг. Использование технологий, в значительной степени аналогичных концепциям, разработанным в Ядро Маха, Spring сконцентрировался на предоставлении более богатой среды программирования, поддерживающей множественное наследование и другие особенности. Spring также был более четко отделен от операционных систем, которые он будет размещать, оторвав его от своих Unix root и даже позволяя запускать несколько ОС одновременно. Разработка прекратилась в середине 1990-х, но несколько идей и некоторый код из проекта позже были повторно использованы в Ява язык программирования библиотеки и Солярис Операционная система.

История

Обложка компакт-диска Spring Research Distribution 1.0

Весна началась окольными путями в 1987 году в рамках Sun and AT&T сотрудничество для создания объединенный UNIX, обе компании решили, что это также хорошая возможность «переопределить UNIX объектно-ориентированным способом».^[1] Однако после нескольких встреч эта часть проекта умерла.

Sun решила сохранить свою команду и вместо этого исследовать систему на передний край. Помимо объединения разновидностей Unix, новая система также сможет запускать практически любую другую систему, причем распределенным образом. Система впервые была запущена в «полном» виде в 1993 году, и по ней был подготовлен ряд исследовательских работ. В 1994 году по некоммерческой лицензии был выпущен "исследовательский" релиз, но неясно, насколько широко он использовался. Команда распалась и перешла к другим проектам в Sun, используя некоторые концепции Spring во множестве других проектов.

Фон

Проект Spring стартовал вскоре после выпуска Mach 3. В более ранних версиях Mach был просто модифицированной версией существующего BSD ядра, но в Mach 3 службы Unix были отделены и запускались как программа пользовательского пространства, как и любая другая, концепция Mach, называемая сервер. Данные, которые обычно были бы частными в ядре в традиционной системе Unix, теперь передавались между серверами и пользовательскими программами с использованием межпроцессного взаимодействия (IPC) система, заканчивающаяся на порты которые проводились в обеих программах. Mach реализовал эти порты в ядре, используя виртуальная память перемещать данные из программы в программу, полагаясь на блок управления памятью (MMU) и копирование при записи алгоритм, чтобы сделать это с разумной производительностью.

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

Эта возможность особенно понравилась таким компаниям, как IBM, которые уже поддерживали несколько различных систем, и рассматривали Mach как способ объединить их с общим базовым кодом. На самом деле это было не так просто. Mach принял несколько решений на низком уровне, что сделало любую систему, работающую на нем, до некоторой степени Unix-подобной. Наиболее примечательной была система безопасности, созданная на основе довольно негибкой унаследованной модели программ Unix. Кроме того, система IPC оказалась серьезной проблемой производительности, хотя природа этой проблемы не прояснилась позже. Производительность была настолько низкой, что многие коммерческие проекты по переносу существующих операционных систем на Mach, особенно IBM ОС на рабочем месте, в конечном итоге были заброшены.

Обоснование

Хотя Sun также была заинтересована в поддержке нескольких операционных систем, их потребности были далеко не такими острыми, как IBM или Apple. К этому моменту они уже переместили платформы с их ранних 68 тыс. на базе машин к своим SPARC и их операционная система Solaris на базе UNIX System V пришла на смену SunOS на базе BSD. Проблемы Sun были несколько более тонкими: сохранение интереса разработчиков к версии Sun Unix; и, позволяя их системе масштабироваться вниз на более мелкие устройства, такие как телеприставки. Система на основе микроядра будет особенно полезна в этой последней роли.

Spring сосредоточился на «программируемости»; упрощая разработку системы. Основным дополнением в этом отношении было развитие богатого язык определения интерфейса (IDL), который экспортировал интерфейсы со значительно большим объемом информации, чем тот, который используется в Mach. Помимо функций и их параметров, интерфейсы Spring также включали информацию о том, какие ошибки могут возникать, и пространство имен они принадлежат. При наличии правильного языка программы, включая серверы операционной системы, могут импортировать несколько интерфейсов и комбинировать их, как если бы они были объектами, родными для этого языка, в частности C ++. Некоторое время спустя Spring IDL был принят с небольшими изменениями в качестве CORBA IDL.

Spring также исследовал ряд конкретных достижений программного обеспечения в файловых системах, виртуальной памяти и производительности IPC. Результатом стала единая Unix-подобная система с гораздо большей производительностью, чем Mach. Некоторые из этих изменений подробно описаны ниже.

Описание

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

Ядро

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

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

Ядро Spring не является многопоточным. Обычно это исключает его использование в в реальном времени настройки, но не совсем понятно, что так. Обычно ядра должны быть многопоточными, чтобы обеспечить длительную задачу, такую ​​как диск Ввод / вывод не связывает систему и не препятствует своевременному обслуживанию следующего звонка; в Spring ядро ​​почти сразу передает подавляющее большинство запросов на серверы, поэтому в этой модели только серверы, теоретически, должны быть распределены по потокам.

Модель IPC

Одним из основных различий между Mach и Spring была система IPC. В Mach система была устроена как набор односторонних асинхронных трубок (порты) между программами, концепция, полученная из Unix каналы. Однако в программировании наиболее распространенным методом связи является вызов процедуры, или вызов / возврат, которые Mach напрямую не поддерживает. Семантика вызова / возврата может поддерживаться только с помощью дополнительного кода в библиотеках более высокого уровня на основе базового механизма портов, что усложняет работу.

Вместо этого Spring напрямую поддерживает семантику вызова / возврата в базовой системе связи. Это привело к изменению терминологии с порты в Махах, чтобы двери весной. Двери были известны только ядру; программам вручали "ручку" двери с идентификатором, уникальным для этой программы. Система работала аналогично портам для исходного сообщения; сообщения, отправленные в дверь, проверялись ядром, чтобы найти целевое приложение и преобразовать дверную ручку, но затем ядро ​​записало небольшие объемы информации от вызывающего, чтобы иметь возможность быстро возвращать данные. Это ускорило возврат примерно на 40%.

Кроме того, модель Маха была асинхронной - вызов возвращался, если и когда на сервере были данные. Это следовало исходной модели каналов Unix, которая позволяла запускать другие программы, если сервер был занят. Однако для системы вызова / возврата это имеет серьезные недостатки, потому что планировщик задач должен запускаться, чтобы выбрать следующую программу для обслуживания. Надеюсь, это был сервер, с которого вызов запрашивал данные, но это не было гарантировано. В Spring IPC синхронный; управление немедленно передается серверу без запуска планировщика, что сокращает время приема-передачи в обычном случае, когда сервер может немедленно вернуться.

Под Махом виртуальная память система, поддерживаемая блок управления памятью (MMU), как ожидалось, предоставит облегченное решение для копирования данных путем простого отображения одних и тех же данных в памяти в двух программах. На самом деле это решение было совершенно неэффективным, так как многие MMU имели конструктивные особенности, которые делали это отображение медленным или даже невозможным.

В отличие от универсального решения Mach для IPC, Spring использовала множество методов для физической передачи данных между программами. Один из них, массовый путь, был в основном идентичен портам и сообщениям Mach, но на практике групповой путь был наименее распространенным типом сообщений. Для небольших сообщений Spring предоставил ванильный путь, который напрямую копировал данные из одного пространства в другое, что оказалось быстрее, чем отображение памяти в реальном мире для менее чем 5 КБ данных.

В быстрый путьразрешены для чрезвычайно быстрых вызовов - по крайней мере, при работе на SPARC платформы. В быстром пути использовалась уникальная «пололовушка», чтобы избежать большей части переключение контекста накладные расходы, которые преследовали системы Маха. Вместо сохранения всего состояния процессора - обычной процедуры в случае ловушки в ядре - Spring сохранил только 16 верхних регистров SPARC, число, которое было определено конкретными деталями реализации архитектуры SPARC. Остальные части стека регистров были невидимы для получателя с помощью SPARC. WIM инструкция, обеспечивающая определенный уровень безопасности. Быстрый путь сильно напоминает классический вызов процедуры в одном приложении, в котором используется зарегистрировать окна на SPARC добавление некоторой работы MMU для перемещения контекста из одной программы в другую.

Быстрый путь был доступен только для вызовов, передающих простые значения, которые не нужно было переводить (например, без ссылок на двери), всего до 16 значений. Хотя это может показаться весьма ограничивающим, fast-path фактически используется подавляющим большинством вызовов Spring - обычно более 80% вызовов и около 60% возвратов. При возврате часто используются большие блоки данных, например, дисковый блок, что объясняет, почему при возврате чаще используются другие системы IPC.

На 32-битный В системах SPARC V8 полный вызов туда и обратно с использованием быстрого пути потребовал чуть более 100 инструкций, что делает его во много раз быстрее, чем типичный вызов Mach. Остается неясным, можно ли реализовать быстрый путь на других машинах, поэтому общее улучшение производительности Spring трудно сравнивать с Mach, который обычно измерялся на IA-32 системы. В частности, полный системный вызов занял менее 20 мкс на 486DX-50 для существующих BSD Unix систем и 114 мкс при Махе. Это привело к падению производительности на 50% и более и обрекло большинство проектов Mach. Напротив, Spring, использующий fast-path, показал время IPC всего 11 мкс на SPARCstation 2.

Виртуальная память

Еще одна важная область улучшения в Spring - реализация виртуальная память (VM), также являющаяся частью ядра. Виртуальная память - это система, которая связывает воедино физическое баран в машине, MMU и дисковой системе, чтобы создать иллюзию, что каждая программа в системе имеет собственный блок RAM, равный максимуму, который может поддерживать машина и операционная система. Наиболее распространенной моделью адресации памяти в компьютерах и операционных системах, использовавшихся в 1980-х и 1990-х годах, была 32-битная модель, обеспечивающая доступ к теоретическому пределу в 4ГиБ памяти, но до начала 2000-х только относительно дорогие компьютеры имели такой объем оперативной памяти. Система VM создает иллюзию большего, используя жесткий диск как вспомогательный магазин, область гораздо более медленной памяти, используемая для разгрузки неактивных частей ОЗУ.

В традиционных Unix-системах виртуальная машина является частью ядра, как и обработчики диска и памяти, которые она связывает вместе. В среде Mach решение о том, где разместить виртуальную машину, не так очевидно - хотя ядро ​​контролирует RAM и MMU, обработчики дисков являются частью внешних клиентских программ. Чтобы решить эту проблему, Mach 3 представил новую двухуровневую систему виртуальных машин с контролем реальной системы виртуальных машин в ядре, которая затем запрашивала внешнее клиентское пространство. пейджер для взаимодействия с дисковой системой для физического копирования памяти. К сожалению, это оказалось серьезной проблемой производительности, требующей нескольких переходов в ядро ​​и из него (с последующим переключением контекста вместе с ним), поскольку различные уровни системы виртуальной машины вызывали друг друга.

У команды Spring было то преимущество, что она могла изучить, что пошло не так с моделью Маха, и исправить это. Результатом стала намного более четко разделенная система адресные пространства в программах, отображаемых виртуальной машиной в различные объем памяти объекты, которыми, в свою очередь, управлял пейджер для обработки вспомогательного магазина. Когда программа запрашивала данные, этот запрос передавался в систему виртуальной машины в ядре, которая находила соответствующий пейджер и просила его создать и настроить соответствующий объект памяти. В обмен на пейджер был передан кеш-менеджер от виртуальной машины, которая отвечала за отслеживание состояния «чистый / грязный» локального кеша этого объекта памяти. Детали реализации значительно усложнили эту модель, но большая часть этого была скрыта. В конце концов, в базовой системе были пейджеры, отвечающие за память, и адресные пространства, отвечающие за кеши. У этих двоих были четко определенные интерфейсы, позволяющие им передавать команды туда и обратно для синхронизации данных.

Это разделение обязанностей привело к очень реальному повышению производительности. Поскольку программы могут совместно использовать объекты памяти, а системы микроядра, такие как Spring, основаны на идее копирования памяти, Spring позволил программам, разделяющим память таким образом, также совместно использовать ее в системе виртуальной машины. Таким образом, под Mach, если сетевой файловый сервер передает данные программе обе программы будут использовать память в системе виртуальной машины, тогда как в Spring эти два естественно совместно использовать одни и те же объекты памяти, поскольку пейджер, реализующий этот объект памяти, просто вернет другой дескриптор той же памяти. Только внутри виртуальной машины они будут считаться разными объектами и обрабатываться отдельными диспетчерами кешей. Следовательно данные будет кэшироваться в ОЗУ только один раз. Теоретически это могло бы привести к значительно лучшему использованию оперативной памяти в реальном мире.

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

Служба имен

Большинство операционных систем включают в себя множество услуги нейминга. Самый простой пример - файловая система, в которой файлы внутренне упоминаются с помощью «дескриптора», небольшого числа, в то время как отдельный каталог дает имена файлов, с которыми взаимодействуют пользователи. Такая же дихотомия имя / идентификатор встречается во многих других частях типичной системы Unix; принтеры названы в и т.д. / printcap файла, небольших чисел и строк в переменных среды и сетевых расположений в DNS. Каждая из этих систем давала свои собственные имена с индивидуальным API, заставляя разные объекты казаться совершенно разными даже в концепции.

Другие системы пытались добавить системы именования к существующим системам Unix, но обычно это были «прикрытия» над существующей функциональностью, которые просто собирали все имена из этих различных сервисов и представляли их в одной коллекции. Из-за того, что они полагались на знания о базовой структуре системы, они, как правило, были довольно негибкими, что затрудняло добавление новых сервисов. Кажется, от этого мало пользы.

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

У Mach не было какой-либо службы имен для своих портов. Это оказалось серьезной проблемой, потому что программы должны были заранее знать, какие серверы они должны были вызвать, чтобы попросить ядро ​​предоставить порт. Это означало, что заменить функциональность было намного сложнее, чем следовало бы; например, новый сервер печати должен располагаться на тех же портах, что и старый: не было бы возможности запустить два рядом друг с другом для разработки. Если бы порты вместо этого упоминались по имени, серверы могли бы располагаться на разных портах и ​​просто использовать одно и то же имя. Эта функциональность, предоставляемая сервером имен, считалась очень важной в Spring.

Подход Spring по существу перевернул систему Plan 9: в Spring файловая система была одним из примеров сервера, который использовал единую унифицированную службу имен. Та же служба может использоваться для именования файлов на диске, переменных среды, аппаратных устройств, программ и даже объектов внутри программ. Система была иерархической, только система пространство имен напрямую поддерживалось сервером, который запускался во время загрузки. Затем другие серверы «привязывают» известные им имена к системе, сервер печати создает список принтеров, файловая система выполняет привязку к каталогам подключенных дисков. Таким образом, было построено отображение всех объектов в системе, потенциально во время выполнения, и к ним можно было получить доступ файловым способом, очень похожим на Plan 9. Все они могли быть доступны с помощью единого API, хотя система также предоставил множество библиотек-заглушек, чтобы он выглядел как классические службы, особенно в сервере эмуляции Unix.

Служба имен была также центральным местом для обеспечения безопасности и получения разрешений. Поскольку двери, настоящие аксессуары в Spring, раздавались службой имен, сервер включал в себя полную список контроля доступа система проверки разрешений. Таким образом, помимо предоставления разрешений в файловой системе, в Spring можно управлять любым объектом, используя тот же набор разрешений и пользовательский интерфейс. Сравните это с Windows NT например, который включает около десятка систем разрешений (файловая система, DCOM, доступ SQL, IIS и т. д.), каждая из которых должна быть настроена отдельно. Для повышения производительности в систему была включена концепция доверия, позволяющая серверам имен предполагать, что запросы от других серверов действительны. Например, если пользователь запросил у файлового сервера доступ к файлу, сервер имен системы передал бы запрос файловой системе, которая немедленно его обработала. Однако, поскольку пользователь не был известен, ACL будет проверяться на соответствие файлу, к которому осуществляется доступ.

Группы связанных имен были известны как контексты. Контексты также были именами и, таким образом, похожи на концепцию файловой системы каталога. Пользователи могли создавать свои собственные контексты из, казалось бы, несвязанных объектов; принтеры, использующие полностью отдельные драйверы (серверы), могут быть собраны в один список, файл может иметь разные имена в разных местах (или для разных пользователей), или может быть создан единый домен, содержащий все личные файлы в нем для целей поиска. Таким образом, Spring позволил «объединить» файловые каталоги, чего не хватало в традиционном Unixen.

Spring не включал встроенный постоянство объекта система, но служба имен была постоянной и могла использоваться для поиска объектов подобным образом. В некоторой степени серия серверов, запускаемых во время загрузки, обеспечивала постоянное пространство имен, которое пережило загрузку, поскольку они копировали свои имена на один и тот же сервер. Теоретически система могла бы позволить серверу имен предоставлять систему «ленивого запуска», не запуская сетевой сервер, например, пока кто-то его не запросит, но, похоже, он не включает эту функцию. Фактически, разделение пространств имен позволило бы отделить это от службы, которая фактически реализовывала именование дверей, что значительно упростило бы реализацию.

Файловая система

Как было сказано ранее, Spring VM позволяет любой программе определять, какой пейджер ей следует использовать. Кроме того, система Spring была основана на единой универсальной системе именования. Эти две концепции были объединены для создания файловой системы Spring.

Ключом к работе файловой системы Spring была тесная интеграция с системой VM. Поскольку было «известно», что система виртуальных машин будет управлять локальным кешем данных из файловой системы, файловая система была сведена только к структуре команд и представляла собой отдельный пейджер. То есть файловая система отвечала за загрузку и сохранение данных из объектов памяти при необходимости, но кэширование этих данных будет обрабатываться для этого виртуальной машиной. Как упоминалось ранее, это означает, что в Spring файл существует в ОЗУ только в одном месте, независимо от того, как он используется программами в системе.

Spring использовал два типа файловых систем: локальная файловая система который был похож на наиболее распространенные системы Unix, а также кеширующая файловая система для сетевых устройств. Система кэширования демонстрирует полезность разделения виртуальной машины / пейджера Spring, используя ту же физическую память виртуальной машины, которую он должен был бы использовать обычно, CFS закоротил все запросы чтения в локальный кеш и выполнял ленивую обратную запись каждые 30 секунд в исходную файловую систему. Это было бы особенно заметно, если бы общие каталоги Unix загружались по сети, обычная установка для лабораторий рабочие станции. Большинство систем Unix используют аналогичные механизмы кэширования по тем же причинам производительности, но в конечном итоге будут использовать оперативную память дважды, один раз в кеше и снова в программах, использующих ее. CFS также кэширует имена из удаленной системы, что значительно ускоряет начальный обход каталога и открытие запросов.

Файловая система Spring также является поставщиком контекста службы имен, лениво отображая каталоги из структуры на диске в новые контексты в службе имен. Затем к ним можно было получить доступ с помощью универсального API именования или, альтернативно, через библиотеку эмуляции Unix, которая представила их как традиционную файловую систему unix.

Обратите внимание, что Spring использует термин файловая система несколько сбивает с толку. В обычном использовании термин относится к определенному способу физического хранения файлов на диске.

Эмуляция Unix

Spring также требовался для поддержки существующих приложений Unix, составляющих основу бизнеса Sun. Для этого Spring также поставляется с двумя ключевыми расширениями: сервером процессов Unix, имитирующим полную версию Unix, и переписанным стандартным libc библиотека называется libue который перенаправлял запросы ядра Unix на различные серверы. Например, приложение Unix, которому требуются файловые или сетевые службы, будет направлено на связанный сервер Spring, в то время как приложение, которое хочет вывести список запущенных в данный момент программ, будет направлено на сервер процесса Unix. Сервер обработки также отвечал за обработку сигналы, концепция, не имеющая аналога в Spring - и на самом деле она была не нужна, кроме как для обратной совместимости, поскольку сигналы по сути являются негибким одноцелевым механизмом IPC.

Для запуска приложения Unix под Spring требовалось, чтобы оно было повторно связано с libue; система поставляется с большинством основных утилит Unix и сервером X11, подключенным и готовым к использованию. Однако этот метод совместимости не был ни невидимым, ни гарантированно работающим; В документах Spring отмечается, что «многие» приложения будут работать без изменений (предположительно, кроме повторного связывания), но не упоминают, каких проблемных областей следует ожидать разработчику, если они этого не сделают.

Субподряды

Хотя инженеры Sun, работающие над проектом, не имели прямого отношения к Spring как таковой, они обнаружили, что существующие механизмы поддержки различных видов вызовов не были четко определены. Чтобы обеспечить более богатый интерфейс, они разработали концепции субподряды.

Другие системы

Sun добавила "Unixified" версию Двери в Солярис.

За годы, прошедшие после завершения работы над системой Spring, работа над операционными системами в целом практически прекратилась. Рынок быстро расслаивается на мир, в котором доминируют Windows и Unix-подобные операционные системы, поэтому для любой другой системы, похоже, остаются только нишевые рынки. Кроме того, плохая производительность Mach 3, похоже, вырвала ветер из-под парусов многих проектов.

Тем не менее были и более новые системы. В частности, L4 микроядро, разделяет ряд функций с ядром Spring. В частности, он также использует синхронную систему вызова / возврата для IPC и имеет аналогичную модель виртуальной машины. L4 до сих пор концентрировался почти исключительно на самом ядре; нет ничего похожего на службу имен, модель безопасности или файловую систему Spring.

Рекомендации