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

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

История [ править ]

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

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

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

Фон [ править ]

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

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

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

Обоснование [ править ]

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

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

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

Описание [ править ]

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

Ядро [ править ]

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

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

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

Модель IPC [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Это разделение обязанностей привело к очень реальному повышению производительности. Поскольку программы могут совместно использовать объекты памяти, а системы микроядра, такие как Spring, основаны на идее копирования памяти, Spring позволил программам, разделяющим память таким образом, также совместно использовать ее в системе виртуальных машин. Таким образом, в Mach, если сетевой файловый сервер передает данные программе, обе программы в конечном итоге будут использовать память в системе виртуальной машины, тогда как в 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 VM позволяет любой программе определять, какой пейджер ей следует использовать. Кроме того, система Spring была основана на единой универсальной системе именования. Эти две концепции были объединены для создания файловой системы Spring.

Ключом к работе файловой системы Spring была тесная интеграция с системой виртуальных машин. Поскольку было «известно», что система виртуальных машин будет управлять локальным кешем данных из файловой системы, файловая система была сведена только к структуре команд и представляла собой отдельный пейджер. То есть файловая система отвечала за загрузку и сохранение данных из объектов памяти, когда это необходимо, но кэширование этих данных будет обрабатываться для этого виртуальной машиной. Как упоминалось ранее, это означает, что в 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 добавила в Solaris "Unixified" версию Doors .

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

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

Ссылки [ править ]