Primavera (sistema operativo)

El núcleo de Spring se dividió en dos partes: un sistema de memoria virtual y el núcleo . Si bien el núcleo equivale a solo una parte del núcleo de Mach, los núcleos de ambos sistemas operativos son lo suficientemente análogos como para considerar que realizan la misma función.

El núcleo de Spring incluye únicamente la funcionalidad y el estado más básicos necesarios para dar soporte a las aplicaciones del lado del usuario. Principalmente, esto incluye el estado para mantener listas de programas en ejecución ( dominios ) y sus hilos, así como los enlaces de comunicación entre ellos ( puertas ).

El núcleo de Spring no es multihilo. Normalmente, esto impediría su uso en entornos en tiempo real , pero no está claro que sea así. Por lo general, los núcleos necesitan ser multihilo para garantizar que una tarea de larga duración, como la E/S de disco , no sature el sistema e impida que una llamada posterior se atienda a tiempo; en Spring, el núcleo transfiere casi de inmediato la gran mayoría de las solicitudes a los servidores, por lo que, en teoría, solo los servidores necesitan ser multihilo.

Una diferencia fundamental entre Mach y Spring radicaba en el sistema IPC. En Mach, el sistema se organizaba mediante un conjunto de canales asíncronos unidireccionales ( puertos ) entre programas, un concepto derivado de las tuberías de Unix . Sin embargo, en programación, el método de comunicación más común es la llamada a procedimiento , o llamada/retorno, que Mach no admitía directamente. La semántica de llamada/retorno solo podía implementarse mediante código adicional en bibliotecas de nivel superior basadas en el mecanismo de puertos subyacente, lo que añadía complejidad.

Spring, en cambio, implementó directamente la semántica de llamada/retorno en su sistema de comunicaciones básico. Esto dio lugar a un cambio de terminología, pasando de " puertos " en Mach a " puertas " en Spring. Las puertas eran conocidas únicamente por el kernel; a los programas se les asignaba un identificador único para cada puerta. El sistema funcionaba de forma similar a los puertos para el mensaje inicial: el núcleo examinaba los mensajes enviados a una puerta para encontrar la aplicación de destino y traducir el identificador, pero luego registraba pequeñas cantidades de información del emisor para poder devolver los datos rápidamente. Esto aceleraba la respuesta en aproximadamente un 40 %.

Además, el modelo Mach era asíncrono : la llamada devolvía un resultado si el servidor tenía datos. Esto seguía el modelo original de tuberías de Unix, que permitía que otros programas se ejecutaran si el servidor estaba ocupado. Sin embargo, para un sistema de llamada/retorno, esto presenta serios inconvenientes, ya que el planificador de tareas debe ejecutarse para seleccionar el siguiente programa que se atenderá. Idealmente, este sería el servidor desde el que la llamada solicitaba datos, pero esto no estaba garantizado. Con Spring, la comunicación entre procesos (IPC) es síncrona; el control se transfiere inmediatamente al servidor sin ejecutar el planificador, lo que mejora el tiempo de respuesta en el caso común en que el servidor puede devolver un resultado de inmediato.

En Mach, se esperaba que el sistema de memoria virtual , respaldado por la unidad de gestión de memoria (MMU), proporcionara una solución ligera para copiar datos, simplemente asignando los mismos datos en la memoria de ambos programas. En realidad, esta solución no era nada eficiente, ya que muchas MMU presentaban características de diseño que hacían que esta asignación fuera lenta o incluso imposible.

A diferencia de la solución única de Mach para la comunicación entre procesos (IPC), Spring utilizaba diversos métodos para transferir datos físicamente entre programas. Uno de ellos, la ruta de transferencia masiva (bulk-path ), era prácticamente idéntico a los puertos y mensajes de Mach, pero en la práctica era el tipo de mensaje menos común. Para mensajes más pequeños, Spring proporcionaba la ruta estándar (vanilla-path ), que copiaba directamente los datos de un espacio a otro, lo que resultó ser más rápido que el mapeo de memoria en la práctica para datos de menos de 5 KB.

La ruta rápida permitía invocaciones extremadamente veloces , al menos al ejecutarse en plataformas basadas en SPARC . Esta ruta utilizaba una técnica única de "semitrampa" para evitar gran parte de la sobrecarga de cambio de contexto que afectaba a los sistemas Mach. En lugar de guardar todo el estado del procesador (el procedimiento habitual en el caso de una interrupción en el núcleo), Spring solo guardaba los 16 registros SPARC superiores, un número definido por detalles específicos de la arquitectura SPARC. Las demás partes de la pila de registros se volvían invisibles para el receptor mediante la WIMinstrucción SPARC, lo que proporcionaba cierto nivel de seguridad. La ruta rápida se asemeja mucho a una llamada a procedimiento clásica dentro de una misma aplicación, que utiliza ventanas de registro en SPARC, añadiendo trabajo a la MMU para transferir el contexto de un programa a otro.

La vía rápida solo estaba disponible para llamadas que pasaban valores simples que no necesitaban ser traducidos (por ejemplo, sin referencias a puertas), con un máximo de 16 valores en total. Aunque esto podría parecer bastante limitante, la gran mayoría de las llamadas en Spring utilizan la vía rápida: generalmente más del 80 % de las llamadas y alrededor del 60 % de las respuestas. Las respuestas suelen contener grandes bloques de datos, como un bloque de disco, lo que explica por qué las respuestas utilizaban con mayor frecuencia los otros sistemas de comunicación entre procesos (IPC).

En los sistemas SPARC V8 de 32 bits , una llamada de ida y vuelta completa utilizando la ruta rápida requirió poco más de 100 instrucciones, lo que la hace muchas veces más rápida que una llamada Mach típica. Aún no está claro si la ruta rápida podría implementarse en otras máquinas, por lo que la mejora general del rendimiento de Spring es difícil de comparar con Mach, que normalmente se medía en sistemas IA-32 . Específicamente, una llamada al sistema completa tardó menos de 20 μs en un 486DX-50 para los sistemas BSD Unix  existentes , y 114 μs bajo Mach. Esto provocó una pérdida de rendimiento del 50 % o más, y condenó a la mayoría de los proyectos Mach. En contraste, Spring utilizando la ruta rápida presumió de un tiempo IPC de solo 11 μs en una SPARCstation 2 .  

Otra área clave de mejora en Spring fue la implementación del sistema de memoria virtual (VM), también parte del kernel. La memoria virtual es un sistema que vincula la memoria de acceso aleatorio (RAM) física de una máquina, la MMU y el sistema de disco para crear la ilusión de que cada programa en el sistema tiene su propio bloque de RAM igual al máximo que la máquina y el sistema operativo pueden soportar. El modelo de direccionamiento de memoria más común en las computadoras y sistemas operativos utilizados en las décadas de 1980 y 1990 era de 32 bits, que proporcionaba acceso a un límite teórico de 4 GiB de memoria, pero hasta principios de la década de 2000, solo las computadoras relativamente caras tenían tanta RAM física. El sistema VM crea la ilusión de más memoria al usar el disco duro como almacenamiento de respaldo , un área de memoria mucho más lenta que se usa para descargar porciones inactivas de la RAM. 

En los sistemas Unix tradicionales, la máquina virtual (VM) forma parte del núcleo, al igual que los gestores de disco y memoria a los que está vinculada. En Mach, la decisión de dónde ubicar el sistema de VM no es tan obvia: aunque el núcleo controla la RAM y la MMU, los gestores de disco pertenecen a programas cliente externos. Para solucionar este problema, Mach 3 introdujo un nuevo sistema de VM de dos capas, con el control del sistema de VM propiamente dicho en el núcleo, que luego solicitaba a un paginador externo del espacio del cliente que interactuara con el sistema de disco para copiar físicamente la memoria. Desafortunadamente, esto resultó ser un grave problema de rendimiento, ya que requería varias entradas y salidas del núcleo (con los consiguientes cambios de contexto) a medida que las distintas capas del sistema de VM se comunicaban entre sí.

El equipo de Spring tuvo la ventaja de poder examinar qué falló en el modelo Mach y corregirlo. El resultado fue un sistema de espacios de direcciones mucho más claramente separado en los programas, mapeados por la máquina virtual en varios objetos de memoria , que a su vez eran administrados por un paginador para respaldar el manejo de almacenamiento. Cuando un programa solicitaba datos, la solicitud se pasaba al sistema de la máquina virtual en el núcleo, que encontraba el paginador apropiado y le pedía que creara y configurara un objeto de memoria adecuado. A cambio, el paginador recibía un administrador de caché de la máquina virtual, que se encargaba de mantener un registro del estado de limpieza/modificación de la caché local de ese objeto de memoria. Los detalles de implementación añadieron una complejidad considerable a este modelo, pero la mayor parte de esto estaba oculto. En definitiva, el sistema básico tenía paginadores que se encargaban de la memoria y espacios de direcciones que se encargaban de las cachés. Ambos tenían interfaces bien definidas que les permitían intercambiar comandos para mantener sus datos sincronizados.

Esta división de tareas conllevó una mejora de rendimiento muy significativa. Dado que los programas podían compartir los objetos de memoria, y los sistemas de microkernel como Spring se basan en la idea de copiar la memoria, Spring permitió que los programas que compartían memoria de esta manera también la compartieran en el sistema de la máquina virtual. Así, en Mach, si un servidor de archivos de red entrega datos a un programa, ambos programas terminarán utilizando memoria en el sistema de la máquina virtual, mientras que en Spring compartirían de forma natural los mismos objetos de memoria, ya que el paginador que implementa dicho objeto simplemente devolvería otro identificador para la misma memoria. Solo dentro de la máquina virtual se considerarían objetos diferentes y serían gestionados por gestores de caché independientes. Por lo tanto, los datos solo se almacenarían en caché en la RAM una vez. En teoría, esto podría conducir a un uso de la RAM considerablemente mejor en la práctica.

Además, el uso de paginadores externos con una API bien definida permitió separar el sistema de forma precisa cuando fue necesario. Spring también permitió que los propios programas especificaran qué paginador se adaptaba mejor a sus necesidades, incluso a las suyas propias, facilitando así la implementación de sistemas de máquinas virtuales privadas para cargas de trabajo específicas. Para aplicaciones como servidores de archivos , servidores web y sistemas de gestión de bases de datos , las máquinas virtuales y los sistemas de archivos personalizados suelen mejorar drásticamente el rendimiento.

La mayoría de los sistemas operativos incluyen diversos servicios de nombres . El ejemplo más básico es un sistema de archivos, donde los archivos se identifican internamente mediante un identificador numérico, mientras que un directorio independiente proporciona los nombres de archivo con los que interactúan los usuarios. Esta misma dicotomía entre nombre e identificador se da en muchas otras partes del sistema Unix típico: las impresoras se nombran en el etc/printcaparchivo, los números y cadenas de texto en las variables de entorno, y las ubicaciones de red en el DNS. Cada uno de estos sistemas proporcionaba sus propios nombres, con una API personalizada , lo que hacía que los diferentes objetos parecieran completamente distintos incluso conceptualmente.

Otros sistemas intentaron añadir sistemas de nombres a los sistemas Unix existentes, pero generalmente se trataba de "capas" que ocultaban la funcionalidad existente y simplemente recopilaban los nombres de los distintos servicios y los presentaban en una sola colección. Debido a que dependían del conocimiento de la estructura subyacente del sistema, solían ser bastante inflexibles, lo que dificultaba la incorporación de nuevos servicios. Por lo tanto, parece que tuvieron poca acogida.

Solo en un sistema operativo completamente nuevo se podría ofrecer un servicio universal. Por ejemplo, Plan 9 utilizaba el sistema de archivos como un sistema de nombres universal; se podía acceder a todo, desde impresoras hasta ventanas, mediante su nombre a través del sistema de archivos. Esto representa una extensión del concepto original de Unix, que había ido desapareciendo gradualmente a medida que se añadían más y más funcionalidades con el paso de los años.

Mach no disponía de ningún servicio de nombres para sus puertos. Esto resultó ser un problema grave, ya que los programas debían saber de antemano a qué servidores debían llamar para solicitar al kernel que les proporcionara un puerto. Esto implicaba que reemplazar funcionalidades era mucho más difícil de lo que debería haber sido; por ejemplo, un nuevo servidor de impresión debía estar en los mismos puertos que el anterior: no habría forma de ejecutar dos en paralelo para el desarrollo. Si los puertos se identificaban por su nombre, los servidores podían estar en puertos diferentes y simplemente usar el mismo nombre. Esta funcionalidad, proporcionada por un servidor de nombres, se consideraba de suma importancia en Spring.

El enfoque de Spring invirtió esencialmente el sistema Plan 9: bajo Spring, el sistema de archivos era un ejemplo de servidor que utilizaba un único servicio de nombres unificado. Este mismo servicio podía usarse para nombrar archivos en disco, variables de entorno, dispositivos de hardware, programas e incluso objetos dentro de los programas. El sistema era jerárquico: solo el systemespacio de nombres era compatible directamente, mediante un servidor que se iniciaba al arrancar el sistema. Otros servidores se encargaban de "vincular" los nombres que conocían al sistema; por ejemplo, el servidor de impresión generaba una lista de impresoras y el sistema de archivos vinculaba los directorios de los discos conectados. De esta forma, se creaba una correspondencia de todos los objetos del sistema, potencialmente en tiempo de ejecución, y se podía acceder a ellos de forma similar a los archivos, muy parecida a Plan 9. Se podía acceder a todos ellos mediante una única API, aunque el sistema también proporcionaba diversas bibliotecas auxiliares para que se comportara como servicios clásicos, especialmente en el servidor de emulación de Unix.

El servidor de nombres también era la ubicación central para la seguridad y la gestión de permisos. Dado que las puertas, los verdaderos responsables del acceso en Spring, eran gestionadas por el servidor de nombres, este incluía un sistema completo de verificación de permisos basado en listas de control de acceso (ACC) . Así, además de proporcionar permisos en el sistema de archivos, en Spring cualquier objeto podía controlarse mediante el mismo conjunto de permisos e interfaz de usuario. Compárese esto con Windows NT , por ejemplo, que incluye una docena de sistemas de permisos (sistema de archivos, DCOM, acceso SQL, IIS, etc.), todos los cuales deben configurarse por separado. Para mejorar el rendimiento, el sistema incluía el concepto de confianza, que permitía a los servidores de nombres asumir que las solicitudes de otros servidores eran válidas. Por ejemplo, si un usuario solicitaba al servidor de archivos acceso a un archivo, el servidor de nombres del sistema reenviaba la solicitud al sistema de archivos, que la atendía de inmediato. Sin embargo, dado que el usuario era desconocido, se verificaban las listas de control de acceso (ACC) con respecto al archivo al que se accedía.

Los grupos de nombres relacionados se conocían como contextos . Los contextos también eran nombres, y por lo tanto, similares al concepto de directorio en los sistemas de archivos. Los usuarios podían crear sus propios contextos a partir de objetos aparentemente no relacionados; las impresoras que utilizaban controladores (servidores) completamente diferentes podían agruparse en una sola lista, un archivo podía tener nombres diferentes en diferentes ubicaciones (o para diferentes usuarios), o se podía crear un único dominio que contuviera todos los archivos personales para fines de búsqueda. De esta manera, Spring permitía "unir" directorios de archivos, una característica útil de la que carecía el Unix tradicional .

Spring no incluía un sistema de persistencia de objetos integrado , pero el servicio de nombres era persistente y podía utilizarse para encontrar objetos de esta manera. En cierta medida, la serie de servidores que se iniciaban durante el arranque proporcionaba un espacio de nombres persistente que se mantenía tras el arranque, ya que copiaban sus nombres en el mismo servidor. En teoría, el sistema podría permitir que el servidor de nombres proporcionara un sistema de "inicio diferido", es decir, que no iniciara el servidor de red hasta que alguien lo solicitara, por ejemplo, pero no parece que incluyera esta funcionalidad. De hecho, la separación de los espacios de nombres permitiría separar esta tarea al servicio que implementaba la nomenclatura de las puertas, lo que simplificaría considerablemente la implementación.

La máquina virtual Spring permitía que cualquier programa definiera qué paginador debía usar. Además, el sistema Spring se basaba en un único sistema de nombres universal. Estos dos conceptos se combinaron para crear el sistema de archivos Spring.

La clave del funcionamiento del sistema de archivos de Spring residía en su estrecha integración con el sistema de máquina virtual (VM). Dado que se sabía que el sistema VM gestionaría la caché local de los datos del sistema de archivos, este se redujo a una estructura de comandos y funcionaba como su propio paginador. Es decir, el sistema de archivos se encargaba de cargar y guardar datos de objetos en memoria cuando era necesario, pero el almacenamiento en caché de dichos datos lo gestionaba la VM. Esto significa que, en Spring, un archivo solo existe en la RAM en una ubicación específica, independientemente de cómo lo compartan los programas del sistema.

Spring utilizaba dos tipos de sistemas de archivos: un sistema de archivos local similar al de la mayoría de los sistemas Unix comunes y un sistema de caché para dispositivos de red. El sistema de caché demuestra la utilidad de la división entre máquina virtual y paginador de Spring: utilizando la misma memoria física de la máquina virtual que usaría normalmente, el sistema de caché desviaba todas las solicitudes de lectura a la caché local y realizaba escrituras diferidas cada 30 segundos al sistema de archivos de origen. Esto resultaba especialmente útil al cargar directorios Unix comunes a través de la red, la configuración habitual en laboratorios de estaciones de trabajo . La mayoría de los sistemas Unix utilizan mecanismos de caché similares por las mismas razones de rendimiento, pero acabarían utilizando la RAM dos veces: una en la caché y otra en los programas que la utilizan. El sistema de caché también almacenaba en caché los nombres del sistema remoto, lo que agilizaba considerablemente el recorrido inicial del directorio y las solicitudes de apertura.

El sistema de archivos Spring también funciona como proveedor de contexto para el servicio de nombres, asignando de forma diferida los directorios de la estructura en disco a nuevos contextos en dicho servicio. Estos contextos podían ser accedidos mediante la API de nombres universal o, alternativamente, a través de una biblioteca de emulación Unix que los presentaba como un sistema de archivos Unix tradicional.

Cabe señalar que el uso que hace Spring del término " sistema de archivos" puede resultar algo confuso. En el uso habitual, el término se refiere a una forma particular de almacenar físicamente archivos en un disco.

Spring también necesitaba dar soporte a las aplicaciones Unix existentes, la base del negocio de Sun. Para ello, Spring incluía dos extensiones clave: un servidor de procesos Unix que simulaba un sistema Unix completo y una reescritura de la biblioteca estándar libc llamada libue, que redirigía las solicitudes del kernel Unix a distintos servidores. Por ejemplo, una aplicación Unix que requiriera servicios de archivos o de red se dirigiría al servidor Spring correspondiente, mientras que una que quisiera listar los programas en ejecución se dirigiría al servidor de procesos Unix. El servidor de procesos también se encargaba de gestionar las señales , un concepto que no tenía equivalente en Spring , ni era realmente necesario salvo por motivos de compatibilidad con versiones anteriores, ya que las señales son esencialmente un mecanismo IPC inflexible y de propósito único.

Para ejecutar una aplicación Unix con Spring, era necesario volver a enlazarla con libue ; el sistema incluía la mayoría de las utilidades básicas de Unix y un servidor X11 ya enlazados y listos para usar. Sin embargo, este método de compatibilidad no era invisible ni garantizaba su funcionamiento; la documentación de Spring indica que "muchas" aplicaciones se ejecutarán sin modificaciones (presumiblemente, salvo el reenlace), pero no menciona qué tipo de problemas debería esperar el desarrollador si no lo hacen.

Aunque no está directamente relacionado con Spring en sí, los ingenieros de Sun que trabajaban en el proyecto descubrieron que los mecanismos existentes para admitir diferentes tipos de llamadas no estaban bien definidos. Para proporcionar una interfaz más completa, desarrollaron el concepto de subcontratos .