Jaro (operační systém) - Spring (operating system)

Jaro je ukončený projekt / experiment mikrokernel -na základě objektově orientovaný operační systém vyvinut v Sun Microsystems na počátku 90. let. Používání technologie v zásadě podobné konceptům vyvinutým v EU Machovo jádro Jaro se soustředilo na poskytování bohatšího programového prostředí podporujícího vícenásobné dědictví a další funkce. Jaro bylo také čistěji odděleno od operačních systémů, které by hostilo, čímž se od něj oddělilo Unix root a dokonce umožňuje spuštění několika operačních systémů najednou. Vývoj upadl v polovině 90. let, ale několik nápadů a nějaký kód z projektu byl později znovu použit v Jáva programovací jazyk knihovny a Solaris operační systém.

Dějiny

Spring Research Distribution 1.0 obal na CD

Jaro začalo kruhovým objezdem v roce 1987 jako součást Slunce a AT&T spolupráce na vytvoření sloučený UNIX, obě společnosti se rozhodly, že to byla také dobrá příležitost k „reimplementaci systému UNIX objektově orientovaným způsobem“.^[1] Po několika schůzkách však tato část projektu zemřela.

Sun se rozhodl udržet svůj tým pohromadě a místo toho prozkoumat systém na internetu náběžná hrana. Kromě kombinace unixových příchutí by nový systém mohl také fungovat téměř na jakémkoli jiném systému, a to distribuovaným způsobem. Systém byl poprvé spuštěn „úplným“ způsobem v roce 1993 a vyprodukoval řadu výzkumných prací. V roce 1994 bylo vydáno vydání „kvality výzkumu“ na základě nekomerční licence, ale není jasné, jak široce se toto používalo. Tým se rozpadl a přesunul se k dalším projektům v rámci společnosti Sun, přičemž některé z jarních konceptů použil u řady dalších projektů.

Pozadí

Jarní projekt začal brzy po vydání Machu 3. V dřívějších verzích byla Mach jednoduše upravenou verzí existujícího BSD jádra, ale v Mach 3 byly unixové služby odděleny a spuštěny jako program uživatelského prostoru jako každý jiný, koncept Mach označovaný jako serveru. Data, která by za normálních okolností byla v jádře soukromá v tradičním systému Unix, byla nyní předávána mezi servery a uživatelskými programy pomocí meziprocesová komunikace (IPC), končící na porty které oba programy držely. Mach implementoval tyto porty do jádra pomocí virtuální paměť přesouvat data z programu do programu, spoléhat se na jednotka správy paměti (MMU) a kopírovat při zápisu algoritmus k tomu s přiměřeným výkonem.

Ve svém konečném vývoji by operační systém na Machu sestával z řady takových serverů, z nichž každý by zpracovával konkrétní úkol. Mezi příklady patří souborový systém nebo síťový zásobník. Server operačního systému v takovém systému by byl docela malý, poskytoval by služby jedinečné pro tento operační systém a přesměroval většinu ostatních hovorů na jiné servery. Vzhledem k tomu, že operační systém běžel na jedné sadě společných serverů, mohlo být spuštěno několik serverů současně, což umožnilo jednomu systému „nativně“ podporovat DOS, Unix a další operační systémy současně.

Tato schopnost byla obzvláště vzrušující pro společnosti jako IBM, kteří již podporovali několik různých systémů, a považovali Macha za způsob, jak je kombinovat s běžným základním kódem. Ve skutečnosti to nebylo tak snadné. Mach udělal několik rozhodnutí na nízké úrovni, což způsobilo, že jakýkoli systém na něm běží do určité míry unixově. Nejpozoruhodnější byl bezpečnostní systém, který byl modelován na poměrně nepružném zděděném modelu unixových programů. Systém IPC se navíc ukázal jako hlavní problém s výkonem, ačkoli povaha tohoto problému byla jasná až později. Výkon byl tak špatný, že mnoho komerčních projektů přeneslo stávající operační systémy na Mach, zejména na IBM Pracoviště OS, byli nakonec opuštěni.

Odůvodnění

Ačkoli se Sun také zajímal o podporu více operačních systémů, jejich potřeby nebyly tak naléhavé jako IBM nebo Apple. V tomto okamžiku již přesunuli platformy ze svého raného období 68 tis - stroje založené na jejich SPARC a jejich operační systém Solaris založený na systému UNIX V převzal od jejich SunOS založeného na BSD. Obavy společnosti Sun byly poněkud jemnější: udržování zájmu vývojářů o verzi Unix od společnosti Sun; a umožnění jejich systému škálovat dolů na menší zařízení, jako je set-top boxy. V této druhé roli by byl obzvláště užitečný systém založený na mikrojádrech.

Jaro se soustředilo na „programovatelnost“; což usnadňuje vývoj systému. Primárním přírůstkem v tomto ohledu byl rozvoj bohatých jazyk definice rozhraní (IDL), který exportoval rozhraní se značně větším množstvím informací, než jaké používá Mach. Kromě funkcí a jejich parametrů obsahovala rozhraní Spring také informace o tom, jaké chyby lze vyvolat, a jmenný prostor patří. Programy, včetně serverů operačního systému, by mohly mít správný jazyk a mohly importovat více rozhraní a kombinovat je, jako by to byly objekty nativní pro daný jazyk - zejména C ++. O nějaký čas později bylo přijato jarní IDL s menšími změnami jako CORBA IDL.

Spring také prozkoumal řadu konkrétních softwarových pokroků v oblasti souborových systémů, virtuální paměti a výkonu IPC. Výsledkem byl jediný unixový systém s mnohem lepším výkonem než Mach. Některé z těchto změn jsou podrobně popsány níže.

Popis

Inženýři společnosti Sun použili nestandardní terminologii pro řadu běžných komponent, což činí diskusi o systému poněkud matoucí. Například Mach úkoly jsou označovány jako domén, porty tak jako dveřea jádro jako jádro.

Jádro

Jarní jádro bylo rozděleno do dvou částí: systém virtuální paměti a jádro. I když je jádro ekvivalentní pouze jedné části Machova jádra, jádra každého OS jsou dostatečně analogická, aby mohla být považována za vykonávající stejnou funkci.

Jarní jádro obsahuje pouze nejzákladnější funkce a stav potřebné k podpoře aplikací na straně uživatele. Primárně to zahrnuje stav k udržování seznamů spuštěných programů (domén) a jejich vlákna, jakož i komunikační spojení mezi nimi (dveře).

Jarní jádro není vícevláknové. Normálně by to znemožnilo jeho použití v reálný čas nastavení, ale není jasné, že tomu tak je. Normálně je nutné jádra vláknit, aby byla zajištěna dlouhotrvající úloha, jako je disk I / O nebude uvázat systém a nezabrání včasnému servisu následného hovoru; na jaře jádro téměř okamžitě odevzdá drtivou většinu požadavků na servery, takže podle tohoto modelu je teoreticky nutné pouze podprocesy.

Model IPC

Jedním z hlavních rozdílů mezi Machem a Springem byl systém IPC. V Machu byl systém uspořádán jako sada jednosměrných asynchronních potrubí (porty) mezi programy, koncept odvozený z Unixové trubky. V programování je však nejběžnější způsob komunikace volání procedury nebo volání / zpět, které Mach přímo nepodporoval. Sémantiku volání / návratu bylo možné podporovat pouze prostřednictvím dalšího kódu v knihovnách vyšší úrovně založených na základním mechanismu portů, což zvyšuje složitost.

Jaro místo toho přímo podporuje sémantiku volání / návratu v základním komunikačním systému. To mělo za následek změnu terminologie z porty v Machu dveře na jaře. Dveře byly známé pouze jádru; programům byla předána „rukojeť“ ke dveřím s identifikátorem, který byl pro daný program jedinečný. Systém fungoval podobně jako porty pro počáteční zprávu; zprávy odeslané ke dveřím byly jádrem prozkoumány, aby bylo možné najít cílovou aplikaci a přeložit kliku dveří, ale jádro poté zaznamenalo malé množství informací od volajícího, aby bylo možné rychle vrátit data. To urychlilo návratnost přibližně o 40%.

Machův model byl navíc asynchronní - volání by se vrátilo, kdyby a kdy měl server data. Toto následovalo původní unixový model rour, který umožňoval spuštění jiných programů, pokud byl server zaneprázdněn. Pro systém volání / zpětného volání to však má vážné nevýhody, protože je třeba spustit plánovač úloh, aby vybral další program, který má být obsluhován. Doufejme, že to byl server, ze kterého volání požadovalo data, ale nebylo to zaručeno. Pod Spring je IPC synchronní; řízení je okamžitě předáno na server bez spuštění plánovače, čímž se zlepší čas zpáteční cesty v běžném případě, kdy se server může okamžitě vrátit.

Pod Machem virtuální paměť systém, podporovaný jednotka správy paměti (MMU), se očekávalo, že poskytne odlehčené řešení pro kopírování dat pouhým mapováním stejných dat v paměti do těchto dvou programů. Ve skutečnosti toto řešení nebylo vůbec efektivní, protože mnoho MMU mělo konstrukční funkce, díky nimž bylo toto mapování pomalé nebo dokonce nemožné.

Na rozdíl od Machova univerzálního řešení IPC použila Spring k fyzickému předávání dat mezi programy celou řadu metod. Jedním z nich je hromadná cesta, byl v zásadě totožný s Machovými porty a zprávami, ale v praxi byla hromadná cesta nejméně běžným typem zpráv. Pro menší zprávy poskytla Spring vanilková cesta, který přímo kopíroval data z jednoho prostoru do druhého, něco, co se ukázalo být rychlejší než mapování paměti v reálném světě za méně než 5 kB dat.

The rychlá cestapovoleno pro extrémně rychlé vyvolání - alespoň při spuštění SPARC - založené platformy. Rychlá cesta používala jedinečnou „polopasti“, aby se vyhnula velké části přepínání kontextu režie, která trápila Machovy systémy. Místo uložení celého stavu procesoru - běžný postup v případě pasti do jádra - Spring uložil pouze nejlepších 16 registrů SPARC, číslo, které bylo definováno konkrétními implementačními detaily architektury SPARC. Ostatní části zásobníku registrů byly pro přijímač pomocí SPARC zneviditelněny WIM instrukce poskytující určitou úroveň zabezpečení. Rychlá cesta silně připomíná volání klasické procedury v rámci jedné aplikace, která používá registrovat okna na SPARC, přidání nějaké práce MMU k přesunutí kontextu z jednoho programu do druhého.

Rychlá cesta byla k dispozici pouze pro hovory procházející jednoduchými hodnotami, které se nemuseli překládat (například žádné odkazy na dveře) až s 16 hodnotami celkem. Ačkoli se to zdá být docela omezující, rychlá cesta je ve skutečnosti používána převážnou většinou hovorů na jaře - obecně přes 80% hovorů a přibližně 60% výnosů. Návraty často reagují velkými bloky dat, například blokem disku, což vysvětluje, proč výnosy častěji používají jiné systémy IPC.

Na 32-bit Systémy SPARC V8, úplné zpáteční volání pomocí rychlé cesty trvalo jen něco málo přes 100 instrukcí, což je mnohonásobně rychlejší než typické Machovo volání. Zůstává nejasné, zda lze rychlou cestu implementovat na jiných strojích, či nikoli, takže celkové zlepšení výkonu Spring je obtížné porovnat s Machem, který se obvykle měřil na IA-32 systémy. Konkrétně, u systému 486DX-50 existoval plný syscall pod 20 µs BSD Unix systémy a 114 µs pod Mach. To vedlo k výkonnostnímu zásahu 50% nebo více a odsoudilo většinu Machových projektů. Naproti tomu Spring využívající rychlou cestu se chlubil IPC časem pouze 11 µs na a SPARCstation 2.

Virtuální paměť

Další klíčovou oblastí zlepšení na jaře byla implementace virtuální paměť (VM) systém, který je také součástí jádra. Virtuální paměť je systém, který spojuje fyzické RAM ve stroji, MMU a diskovém systému vytvářejí iluzi, že každý program v systému má svůj vlastní blok RAM rovný maximu, které může stroj a operační systém podporovat. Nejběžnější model adresování paměti v počítačích a operačních systémech používaných v 80. a 90. letech byl 32bitový, což umožňovalo přístup k teoretickému limitu 4GiB paměti, ale až do časných 2000s, jen relativně drahé počítače by měly tolik fyzické RAM. Systém VM vytváří iluzi více pomocí pevný disk jako záložní obchod, oblast mnohem pomalejší paměti používaná k vykládání neaktivních částí paměti RAM.

V tradičních unixových systémech je VM součástí jádra, stejně jako diskové a paměťové manipulátory, které spojuje dohromady. Podle Macha není rozhodnutí, kam umístit systém VM, tak zřejmé - ačkoli jádro řídí RAM a MMU, obslužné rutiny disků jsou součástí externích klientských programů. K vyřešení tohoto problému zavedl Mach 3 nový dvouvrstvý systém VM s ovládáním skutečného systému VM v jádře, který by se poté zeptal externího klientského prostoru pager interagovat s diskovým systémem a fyzicky kopírovat paměť. Bohužel se to ukázalo jako vážný problém s výkonem, který vyžadoval několik cest dovnitř a ven z jádra (s výslednými přepínači kontextu), protože různé vrstvy systému VM se navzájem nazývaly.

Jarní tým měl tu výhodu, že mohl zkoumat, co se stalo s Machovým modelem, a opravit to. Výsledkem byl mnohem čistěji oddělený systém adresní prostory v programech, mapovaných VM na různé Paměť objekty, které byly zase spravovány a pager pro doprovodnou manipulaci s obchodem. Když program vytvořil požadavek na data, požadavek byl předán systému VM v jádře, který by našel vhodný pager a požádal ho o vytvoření a nastavení příslušného paměťového objektu. Výměnou byl pager předán a správce mezipaměti z virtuálního počítače, který byl zodpovědný za sledování stavu čisté / špinavé místní mezipaměti daného paměťového objektu. Podrobnosti implementace přidaly tomuto modelu značnou složitost, ale většina z toho byla skrytá. Nakonec základní systém měl pagery, které měly na starosti paměť, a adresní prostory, které měly na starosti mezipaměti. Ti dva měli dobře definovaná rozhraní, která jim umožňovala předávat příkazy tam a zpět, aby byla jejich data synchronizovaná.

Toto rozdělení povinností vedlo k jednomu velmi reálnému zlepšení výkonu. Vzhledem k tomu, že programy mohly sdílet paměťové objekty a systémy microkernel, jako je Spring, jsou založeny na myšlence kopírování paměti kolem, Spring umožnil programům, které sdílejí paměť tímto způsobem, sdílet ji také v systému VM. Tedy pod Machem, pokud síťový souborový server předává data programu oba programy nakonec vyčerpají paměť v systému VM, zatímco pod Spring by to udělaly dva přirozeně sdílet stejné paměťové objekty, protože pager implementující tento paměťový objekt by jednoduše vrátil další popisovač do stejné paměti. Pouze uvnitř virtuálního počítače by byly považovány za různé objekty a byly by zpracovány samostatnými správci mezipaměti. Proto data by byl do mezipaměti RAM uložen pouze jednou. Teoreticky by to mohlo vést k podstatně lepšímu využití paměti RAM v reálném světě.

Navíc použití externích pagerů s dobře definovaným API umožnilo, aby byl systém čistě oddělen, když to bylo potřeba. Jaro také umožnilo samotným programům určit, který pager by nejlépe vyhovoval jejich potřebám, včetně nich samotných, což umožnilo jarním programům snadno implementovat soukromé systémy VM pro známé pracovní zátěže. Pro aplikace jako souborové servery, webové servery a systémy pro správu databází, vlastní virtuální počítače a souborové systémy často vedou k dramaticky vylepšenému výkonu.

Názvová služba

Většina operačních systémů zahrnuje řadu služby pojmenování. Nejzákladnějším příkladem je souborový systém, ve kterém jsou soubory interně označovány „handle“, malým počtem, zatímco samostatný adresář udává názvy souborů, se kterými uživatelé interagují. Ke stejnému druhu dichotomie název / identifikátor dochází v mnoha dalších částech typického unixového systému; tiskárny jsou pojmenovány v souboru etc / printcap soubor, malá čísla a řetězce v proměnných prostředí a umístění v síti v DNS. Každý z těchto systémů poskytoval svá vlastní jména se zvykem API, takže různé objekty vypadají zcela odlišně i v konceptu.

Jiné systémy se pokusily přidat pojmenovací systémy ke stávajícím unixovým systémům, ale obecně se jednalo o „kryty“ stávající funkce, které jednoduše shromáždily všechna jména z těchto různých služeb a představily je v jedné kolekci. Vzhledem k tomu, že se spoléhali na to, že věděli o základním uspořádání systému, měli tendenci být spíše nepružní, což usnadňuje přidávání nových služeb. Zdá se, že viděli jen malé využití.

Pouze ve zcela novém operačním systému lze doufat, že poskytneme univerzální službu. Například, Plán 9 použil souborový systém jako univerzální službu pojmenování; ke všem od tiskáren po okna bylo možné prostřednictvím systému souborů přistupovat podle názvu. Jedná se o rozšíření původního konceptu Unixu, které pomalu mizelo, jak se v průběhu let přidávala stále více funkcí.

Mach pro své porty neměl žádnou službu pojmenování. To se ukázalo jako vážný problém, protože programy musely předem vědět, na které servery musí volat, aby mohly jádro požádat o poskytnutí portu. To znamenalo, že nahrazení funkčnosti bylo mnohem obtížnější, než by mělo být; například nový tiskový server musel sedět na stejných portech jako ten starý: neexistoval by způsob, jak spustit dva vedle sebe pro vývoj. Pokud se na porty místo toho odkazuje podle názvu, mohly by servery sedět na různých portech a jednoduše používat stejný název. Tato funkce poskytovaná jmenným serverem byla považována za velmi důležitou na jaře.

Přístup společnosti Spring v zásadě převrátil systém Plan 9: pod Spring byl souborový systém jedním příkladem serveru, který používal službu jednotného názvu. Stejnou službu lze použít k pojmenování souborů na disku, proměnných prostředí, hardwarových zařízení, programů a dokonce i objektů uvnitř programů. Systém byl hierarchický, pouze Systém jmenný prostor byl přímo podporován serverem, který byl spuštěn v době bootování. Ostatní servery by pak „svázaly“ jména, která znali, do systému, tiskový server by vytvořil seznam tiskáren, souborový systém by se svázal v adresářích připojených disků. Tímto způsobem bylo vytvořeno mapování všech objektů v systému, potenciálně za běhu, a bylo k nim možné přistupovat způsobem podobným souboru, který je velmi podobný plánu 9. Ke všem těmto bylo možné přistupovat pomocí jediného rozhraní API, i když systém také poskytl řadu stub knihoven, aby to vypadalo také jako klasické služby, zejména na emulačním serveru Unix.

Jmenná služba byla také ústředním místem pro zabezpečení a povolení. Vzhledem k tomu, že dveře, skutečné přístupové objekty na jaře, byly rozdány jmennou službou, server zahrnoval kompletní seznam řízení přístupu - systém kontroly oprávnění na základě. Kromě poskytování oprávnění k souborovému systému tedy mohl být pod Spring jakýkoli objekt ovládán pomocí stejné sady oprávnění a uživatelského rozhraní. Porovnejte to s Windows NT například, který zahrnuje asi tucet systémů oprávnění (souborový systém, DCOM, přístup SQL, IIS atd.), které je třeba nastavit samostatně. Aby se zlepšil výkon, systém zahrnoval koncept důvěryhodnosti, což umožnilo jmenným serverům předpokládat, že požadavky z jiných serverů jsou platné. Například pokud uživatel požádal souborový server o přístup k souboru, systémový jmenný server předá požadavek souborovému systému, který jej okamžitě vyřídí. Protože však uživatel nebyl znám, byly by seznamy ACL zkontrolovány proti souboru, ke kterému se přistupuje.

Skupiny příbuzných jmen byly známé jako kontexty. Kontexty byly také názvy, a tedy podobné konceptu souborového systému adresáře. Uživatelé mohli vytvářet své vlastní kontexty ze zdánlivě nesouvisejících objektů; tiskárny využívající zcela samostatné ovladače (servery) lze shromáždit do jednoho seznamu, soubor může mít různá jména na různých místech (nebo pro různé uživatele) nebo může být vytvořena jedna doména obsahující každý osobní soubor v něm pro účely vyhledávání. Tímto způsobem Spring umožnil "sjednocování" adresářů souborů, což je užitečná funkce, kterou tradiční Unixen postrádá.

Jaro neobsahovalo vestavěný vytrvalost objektu systému, ale služba jmen byla trvalá a mohla by být použita k vyhledání objektů tímto způsobem. Série serverů spuštěná během bootování do jisté míry poskytovala trvalý prostor jmen, který přežil bootování, když kopírovali své názvy na stejný server. Teoreticky by systém mohl umožnit jmennému serveru poskytnout systém „líného spuštění“ a nespustit síťový server, dokud o něj někdo nepožádá, ale nezdá se, že by obsahoval tuto funkci. Oddělení prostorů jmen by ve skutečnosti umožnilo oddělit to od služby, která pojmenování dveří skutečně implementovala, což značně usnadňuje implementaci.

Souborový systém

Jak již bylo uvedeno dříve, Spring VM umožnil libovolnému programu definovat, jaký pager má použít. Systém Spring byl navíc založen na jediném univerzálním systému pojmenování. Tyto dva koncepty byly zkombinovány tak, aby vznikl souborový systém Spring.

Klíčem k fungování jarního souborového systému byla těsná integrace se systémem VM. Protože bylo „známo“, že systém VM bude spravovat místní mezipaměť dat ze systému souborů, byl systém souborů omezen pouze na strukturu příkazů a byl jeho vlastním stránkovačem. To znamená, že souborový systém byl odpovědný za načítání a ukládání dat z paměťových objektů v případě potřeby, ale ukládání těchto dat do mezipaměti by pro něj zpracoval virtuální počítač. Jak již bylo zmíněno dříve, znamená to, že pod Spring existuje soubor pouze v RAM na jednom místě, bez ohledu na to, jak je sdílen programy v systému.

Spring používal dva druhy souborových systémů, a lokální souborový systém který byl podobný nejběžnějším unixovým systémům, stejně jako a ukládání do mezipaměti souborový systém pro síťová zařízení. Systém ukládání do mezipaměti demonstruje užitečnost Springova rozdělení VM / pager, přičemž používá stejnou fyzickou paměť z VM, kterou by musel normálně používat, CFS zkratoval všechny požadavky na čtení do místní mezipaměti a každých 30 opakoval líné odpisy sekund do systému zdrojového souboru. To by bylo obzvláště pozoruhodné, pokud by se běžné unixové adresáře načítaly po síti, což je běžné nastavení pro laboratoře pracovní stanice. Většina unixových systémů používá podobné mechanismy ukládání do mezipaměti ze stejných důvodů výkonu, ale nakonec by použila RAM dvakrát, jednou v mezipaměti a znovu v programech, které ji používají. CFS také ukládal do mezipaměti jména ze vzdáleného systému, což výrazně urychluje počáteční procházení adresáře a otevřené požadavky.

Souborový systém Spring je také poskytovatelem kontextové služby jmen, která líně mapuje adresáře ze struktury na disku do nových kontextů v názvové službě. K nim pak bylo možné přistupovat pomocí univerzálního pojmenovacího rozhraní API nebo střídavě prostřednictvím emulační knihovny Unix, která je prezentovala jako tradiční unixový systém souborů.

Všimněte si, že Spring tento termín použil souborový systém je poněkud matoucí. Při běžném používání se termín týká konkrétního způsobu fyzického ukládání souborů na disk.

Emulace Unixu

Jaro také potřebovalo podporovat stávající unixové aplikace, základ podnikání Sunu. Za tímto účelem společnost Spring také dodala dvě klíčová rozšíření: procesní server Unix, který napodoboval celý Unix, a přepis standardu libc volala knihovna libue který přesměroval unixové požadavky jádra na různé servery. Například unixová aplikace vyžadující souborové nebo síťové služby by byla směrována na přidružený server Spring, zatímco ta, která chtěla vypsat aktuálně spuštěné programy, by byla směrována na unixový procesový server. Procesní server byl také zodpovědný za zpracování signály, koncept, který neměl na jaře žádný analog - ani nebyl skutečně potřebný jinak než pro zpětnou kompatibilitu, protože signály jsou v podstatě nepružným jednoúčelovým mechanismem IPC.

Spuštění aplikace Unix pod Spring vyžaduje, aby byla znovu propojena libue; systém je dodáván s většinou základních unixových utilit a server X11 je znovu propojen a připraven k použití. Tato metoda kompatibility však nebyla ani neviditelná, ani zaručeně fungovala; Dokumenty z jara upozorňují, že „mnoho“ aplikací bude spuštěno nezměněno (pravděpodobně jinak než opětovné propojení), ale nezmiňují, jaký druh problémových oblastí by měl vývojář očekávat, pokud tak neučiní.

Subdodávky

I když to přímo nesouvisí s jarem jako takovým, inženýři společnosti Sun pracující na projektu zjistili, že stávající mechanismy pro podporu různých příchutí hovorů nebyly dobře definovány. Aby poskytli bohatší rozhraní, vyvinuli koncepty subdodávky.

Jiné systémy

Sun přidal "Unixified" verzi Dveře do Solarisu.

V letech od ukončení práce na jarním systému práce na operačních systémech obecně v podstatě skončila. Vzhledem k tomu, že se trh rychle stratifikoval do světa ovládaného operačními systémy Windows a Unix, zdá se, že pro jakýkoli jiný systém existují pouze specializované trhy. Navíc se zdá, že špatný výkon Machu 3 mnoha projektům vyrazil vítr z plachet.

Přesto existovaly některé novější systémy. Jeden zejména, L4 mikrokernel, sdílí řadu funkcí s Springovým jádrem. Zejména také používá pro IPC synchronní systém volání / zpětného volání a má podobný model virtuálního počítače. L4 se zatím soustředil téměř výhradně na samotné jádro; neexistuje nic analogického s jarní pojmenovací službou, modelem zabezpečení nebo souborovým systémem.

Reference