Mach (núcleo)

Los desarrolladores fueron en bicicleta a almorzar a través de los charcos de barro de la lluviosa Pittsburgh, y Tevanian bromeó diciendo que la palabra "muck" (barro) podría formar un acrónimo inverso para su núcleo de comunicación multiusuario (o multiprocesador universal). El ingeniero italiano de CMU, Dario Giuse ^{[ 5 ], preguntó más tarde al líder del proyecto, Rick Rashid, sobre el título actual del proyecto y recibió "} MUCK " como respuesta, aunque no escrito, sino simplemente pronunciado / mʌk / . Según el alfabeto italiano , escribió "Mach". A Rashid le gustó tanto la ortografía de Giuse, "Mach", que prevaleció . ^{[ 6 ] : 103}

Un concepto clave en el sistema operativo Unix original es la idea de tubería . Una tubería es una abstracción que permite transferir datos como un flujo no estructurado de bytes entre programas. Mediante tuberías, los usuarios pueden conectar varios programas para completar tareas, enviando datos a través de varios programas pequeños consecutivos. Esto contrasta con los sistemas operativos típicos de la época, que requerían un único programa grande capaz de gestionar toda la tarea o, alternativamente, utilizaban archivos para transferir datos, lo cual resultaba costoso en recursos y tiempo.

Las tuberías se construyeron sobre el sistema subyacente de entrada/salida . Este sistema, a su vez, se basa en un modelo donde se espera que los controladores se "bloqueen" periódicamente mientras esperan a que se completen las tareas. Por ejemplo, un controlador de impresora podría enviar una línea de texto a una impresora de línea y luego no hacer nada hasta que la impresora termine de imprimir esa línea. En este caso, el controlador indica que se ha bloqueado y el sistema operativo permite que se ejecute otro programa hasta que la impresora indique que está lista para recibir más datos. En el sistema de tuberías, el recurso limitado era la memoria, y cuando un programa llenaba la memoria asignada a la tubería, se bloqueaba naturalmente. Normalmente, esto provocaba que el programa que la consumía se ejecutara, vaciando la tubería de nuevo. A diferencia de un archivo, donde se debe leer o escribir el archivo completo antes de que el siguiente programa pueda usarlo, las tuberías permitían que el movimiento de datos entre múltiples programas se produjera de forma fragmentada sin ninguna intervención del programador.

La implementación de tuberías en búferes de memoria obligaba a copiar datos de un programa a otro, una operación lenta y que consumía muchos recursos. Esto hacía que el concepto de tuberías no fuera adecuado para tareas que requerían una respuesta rápida o baja latencia, como en la mayoría de los controladores de dispositivos . En cambio, el núcleo del sistema operativo y la mayor parte de su funcionalidad principal se escribieron en un único programa de gran tamaño. Cuando se añadieron nuevas funcionalidades al sistema operativo, como las redes informáticas , el tamaño y la complejidad del núcleo también aumentaron.

Las tuberías de Unix ofrecían un sistema conceptual que permitía construir soluciones de complejidad arbitraria a partir de pequeños programas que cooperaban entre sí. Estos programas más pequeños eran más fáciles de desarrollar y mantener, y contaban con interfaces bien definidas que simplificaban la programación y la depuración. Estas cualidades eran aún más valiosas para los controladores de dispositivos, donde el tamaño reducido y el rendimiento sin errores eran de suma importancia. Existía un fuerte deseo de modelar el núcleo del sistema operativo sobre la misma base de pequeños programas que cooperaban entre sí.

Uno de los primeros sistemas en utilizar un sistema de tuberías como base del sistema operativo fue el núcleo Aleph, desarrollado en la Universidad de Rochester . Este introdujo el concepto de puertos, que esencialmente implementaban memoria compartida . En Aleph, el núcleo se limitaba a proporcionar acceso al hardware, incluyendo la memoria y los puertos, mientras que los programas convencionales que utilizaban el sistema de puertos implementaban todo el comportamiento, desde los controladores de dispositivos hasta los programas de usuario. Este concepto redujo considerablemente el tamaño del núcleo y permitió a los usuarios experimentar con diferentes controladores simplemente cargándolos y conectándolos en tiempo de ejecución. Esto simplificó enormemente los problemas al desarrollar nuevo código para el sistema operativo, que de otro modo requeriría reiniciar la máquina. El concepto general de un núcleo pequeño y controladores externos se conoció como micronúcleo.

Aleph se implementó en los miniordenadores Data General Eclipse y estaba estrechamente vinculado a ellos. Esta máquina distaba mucho de ser ideal, ya que requería la copia de memoria entre programas, lo que generaba una considerable sobrecarga de rendimiento. Además, era bastante cara. No obstante, Aleph demostró la solidez del sistema básico y posteriormente demostró la agrupación de ordenadores mediante la copia de memoria a través de una interfaz Ethernet primitiva .

Por aquella época, una nueva generación de procesadores centrales (CPU) llegaba al mercado, ofreciendo un espacio de direcciones de 32 bits y soporte (inicialmente opcional) para una unidad de gestión de memoria (MMU). La MMU gestionaba las instrucciones necesarias para implementar un sistema de memoria virtual , controlando qué páginas de memoria utilizaban los distintos programas. Esto ofrecía una nueva solución al concepto de puerto, utilizando el mecanismo de copia en escritura (COW) proporcionado por el sistema de memoria virtual. En lugar de copiar datos entre programas, bastaba con indicar a la MMU que proporcionara acceso a esa misma memoria. Este sistema implementaría el sistema de comunicación entre procesos (IPC) con un rendimiento notablemente superior.

Este concepto fue adoptado en Carnegie-Mellon, donde adaptaron Aleph para la estación de trabajo PERQ y lo implementaron mediante copia en escritura. La adaptación fue exitosa, pero el núcleo Accent resultante tenía una utilidad práctica limitada, ya que no ejecutaba el software existente. Además, Accent estaba tan estrechamente ligado a PERQ como Aleph lo estaba a Eclipse.

El principal cambio entre estos núcleos experimentales y Mach fue la decisión de reimplementar una versión del núcleo 4.2BSD existente sobre los conceptos de paso de mensajes de Accent. Dicho núcleo sería compatible binariamente con el software BSD existente , lo que permitiría que el sistema estuviera disponible de inmediato para su uso diario, a la vez que seguiría siendo una plataforma experimental útil. Además, el nuevo núcleo se diseñaría desde el principio para admitir arquitecturas de procesadores múltiples, incluso permitiendo la construcción de clústeres heterogéneos. Para poner en marcha el sistema lo más rápidamente posible, se implementaría partiendo del código BSD existente y reimplementándolo gradualmente como programas basados ​​en la comunicación entre procesos (IPC). De este modo, Mach comenzaría como un sistema monolítico similar a los sistemas UNIX existentes y progresaría con el tiempo hacia el concepto de micronúcleo. ^{[ 4 ]}

Mach comenzó siendo en gran medida un esfuerzo por producir un Accent claramente definido, basado en UNIX y altamente portable. El resultado fue una breve lista de conceptos genéricos: ^{[ 7 ] [ 8 ]}

• Una " tarea " es un conjunto de recursos del sistema que producen "hilos" para ejecutar.
• Un " hilo " es una unidad de ejecución individual, que existe dentro del contexto de una tarea y comparte los recursos de la tarea.
• Un " puerto " es una cola de mensajes protegida para la comunicación entre tareas; las tareas poseen derechos (permisos) de envío y recepción para cada puerto.
• Los " mensajes " son colecciones de datos tipificados, solo se pueden enviar a puertos, no específicamente a tareas o subprocesos.

Mach se basó en los conceptos de comunicación entre procesos (IPC) de Accent, pero lo hizo mucho más similar a UNIX, permitiendo ejecutar programas UNIX con pocas o ninguna modificación. Para ello, Mach introdujo el concepto de puerto, que representa cada extremo de una comunicación bidireccional entre procesos. Los puertos contaban con permisos similares a los de los archivos en UNIX, lo que permitía aplicarles un modelo de protección muy parecido al de UNIX. Además, Mach permitía que cualquier programa gestionara privilegios que normalmente solo se otorgarían al sistema operativo, para que los programas del espacio de usuario pudieran controlar aspectos como el hardware.

En Mach, al igual que en UNIX, el sistema operativo vuelve a ser principalmente un conjunto de utilidades. Como en UNIX, Mach mantiene el concepto de controlador para gestionar el hardware. Por lo tanto, todos los controladores para el hardware actual deben incluirse en el microkernel. Otras arquitecturas basadas en capas de abstracción de hardware o exokernels podrían trasladar los controladores fuera del microkernel.

La principal diferencia con UNIX es que, en lugar de que las utilidades gestionen archivos, pueden gestionar cualquier "tarea". Se trasladó más código del sistema operativo del núcleo al espacio de usuario, lo que dio como resultado un núcleo mucho más pequeño y el surgimiento del término micronúcleo . A diferencia de los sistemas tradicionales, en Mach un proceso, o "tarea", puede constar de varios hilos. Si bien esto es común en los sistemas modernos, Mach fue el primer sistema en definir tareas e hilos de esta manera. La función del núcleo se redujo de ser esencialmente el sistema operativo a ejecutar las "utilidades" y proporcionarles acceso al hardware.

La existencia de puertos y el uso de la comunicación entre procesos (IPC) es quizás la diferencia más fundamental entre Mach y los núcleos tradicionales. En UNIX, llamar al núcleo consiste en una operación denominada llamada al sistema o trampa . El programa utiliza una biblioteca para colocar datos en una ubicación conocida de la memoria y luego provoca un fallo , un tipo de error. Cuando se inicia un sistema, su núcleo se configura para ser el "manejador" de todos los fallos; por lo tanto, cuando un programa provoca un fallo, el núcleo toma el control, examina la información que se le pasa y luego ejecuta las instrucciones.

En Mach, el sistema IPC se utilizaba para esta función. Para acceder a las funcionalidades del sistema, un programa solicitaba al núcleo acceso a un puerto y, a continuación, utilizaba el sistema IPC para enviar mensajes a dicho puerto. Si bien el envío de un mensaje requiere una llamada al sistema, al igual que la solicitud de funcionalidades en otros sistemas, en Mach el núcleo prácticamente solo se encargaba de enviar el mensaje; otro programa se ocupaba de gestionar la solicitud propiamente dicha.

La compatibilidad con hilos y concurrencia se benefició del paso de mensajes con mecanismos IPC, ya que las tareas ahora constan de múltiples hilos de código que Mach puede congelar y descongelar durante el procesamiento de mensajes. Esto permite distribuir el sistema entre varios procesadores, ya sea utilizando memoria compartida directamente, como en la mayoría de los mensajes Mach, o agregando código para copiar el mensaje a otro procesador si es necesario. En un núcleo tradicional, esto es difícil de implementar; el sistema debe asegurarse de que diferentes programas no intenten escribir en la misma región de memoria desde distintos procesadores. Sin embargo, el uso de puertos Mach define y facilita esta implementación, por lo que los puertos Mach se convirtieron en elementos de primera clase en ese sistema.

El sistema IPC inicialmente presentaba problemas de rendimiento, por lo que se desarrollaron varias estrategias para mejorarlo. Al igual que su predecesor, Accent, Mach utilizaba un único mecanismo de memoria compartida para transferir físicamente el mensaje de un programa a otro. Copiar físicamente el mensaje sería demasiado lento, por lo que Mach recurre a la unidad de gestión de memoria (MMU) de la máquina para mapear rápidamente los datos de un programa a otro. Solo si se escriben datos, estos deben copiarse físicamente, un proceso denominado " copia en escritura ".

El núcleo también verificaba la validez de los mensajes para evitar que datos erróneos provocaran el fallo de alguno de los programas del sistema. Los puertos se diseñaron siguiendo el modelo del sistema de archivos UNIX. Esto permite al usuario encontrar puertos utilizando los conceptos de navegación del sistema de archivos, así como asignar derechos y permisos como lo haría en dicho sistema.

El desarrollo bajo un sistema así sería más sencillo. El código en el que se trabajara no solo existiría en un programa tradicional que podría compilarse con las herramientas existentes, sino que también podría iniciarse, depurarse y finalizarse con las mismas herramientas. Con un monokernel, un error en el código nuevo paralizaría toda la máquina y requeriría un reinicio, mientras que con Mach bastaría con reiniciar el programa. Además, el usuario podría personalizar el sistema para incluir o excluir las funciones que necesitara. Dado que el sistema operativo era simplemente una colección de programas, podrían añadir o eliminar partes ejecutándolos o finalizándolos como cualquier otro programa.

Finalmente, bajo Mach, todas estas características fueron diseñadas deliberadamente para ser extremadamente independientes de la plataforma. Para citar un texto sobre Mach:

A diferencia de UNIX, que se desarrolló sin tener en cuenta el multiprocesamiento, Mach incorpora soporte para multiprocesamiento en todo su código. Su soporte para multiprocesamiento es además sumamente flexible, abarcando desde sistemas de memoria compartida hasta sistemas sin memoria compartida entre procesadores. Mach está diseñado para ejecutarse en sistemas informáticos con entre uno y miles de procesadores. Además, Mach se puede portar fácilmente a diversas arquitecturas informáticas. Un objetivo clave de Mach es ser un sistema distribuido capaz de funcionar en hardware heterogéneo. ^{[ 9 ]}

Sin embargo, existen varias desventajas. Una relativamente trivial es la dificultad para encontrar los puertos. En UNIX, este problema se resolvió con el tiempo, ya que los programadores acordaron una serie de ubicaciones "conocidas" en el sistema de archivos para diversas funciones. Si bien este mismo enfoque funcionó también para los puertos de Mach, en Mach se asumía que el sistema operativo era mucho más flexible, con puertos que aparecían y desaparecían constantemente. Sin algún mecanismo para encontrar los puertos y los servicios que representaban, gran parte de esta flexibilidad se perdería.

Mach se implementó inicialmente como código adicional escrito directamente en el núcleo 4.2BSD existente, lo que permitió al equipo trabajar en el sistema mucho antes de su finalización. El trabajo comenzó con el sistema IPC/puerto Accent, que ya era funcional, y continuó con otras partes clave del sistema operativo: tareas, subprocesos y memoria virtual. A medida que se completaban las distintas partes, se reescribieron varias secciones del sistema BSD para que interactuaran con Mach, y durante este proceso también se realizó un cambio en la versión 4.3BSD.

Para 1986, el sistema estaba lo suficientemente completo como para funcionar de forma independiente en el DEC VAX . Si bien no tenía mucha utilidad práctica, se logró el objetivo de crear un microkernel. Pronto le siguieron versiones para el IBM RT PC y para estaciones de trabajo basadas en el Sun Microsystems 68030 , lo que demostró la portabilidad del sistema. En 1987, la lista incluía las máquinas Encore Multimax y Sequent Balance , poniendo a prueba la capacidad de Mach para ejecutarse en sistemas multiprocesador. Ese mismo año se lanzó la versión pública Release 1, y la Release 2 le siguió al año siguiente.

Durante todo este tiempo, la promesa de un microkernel "verdadero" aún no se había cumplido. Estas primeras versiones de Mach incluían la mayor parte de 4.3BSD en el kernel, un sistema conocido como servidor POE, lo que resultaba en un kernel que, de hecho, era más grande que el UNIX en el que se basaba. Sin embargo, la idea era trasladar la capa UNIX del kernel al espacio de usuario, donde sería más fácil trabajar con ella e incluso reemplazarla por completo. Desafortunadamente, el rendimiento resultó ser un problema importante, y se realizaron varios cambios arquitectónicos para solucionarlo. Los engorrosos problemas de licencias de UNIX también afectaron a los investigadores, por lo que este esfuerzo inicial por proporcionar un entorno de sistema similar a UNIX sin licencia siguió utilizándose durante el desarrollo posterior de Mach.

El Mach 3 resultante se lanzó en 1990 y generó un gran interés. Un pequeño equipo había desarrollado Mach y lo había adaptado a diversas plataformas, incluyendo sistemas multiprocesador complejos que causaban serios problemas a los núcleos más antiguos. Esto despertó un considerable interés en el mercado comercial, donde varias empresas estaban considerando cambiar de plataforma de hardware. Si el sistema existente podía adaptarse para ejecutarse en Mach, parecía que sería sencillo cambiar la plataforma subyacente.

Mach recibió un gran impulso en visibilidad cuando la Open Software Foundation (OSF) anunció que alojaría futuras versiones de OSF/1 en Mach 2.5, y que también estaba investigando Mach 3. Mach 2.5 también fue seleccionado para el sistema NeXTSTEP y varios proveedores comerciales de multiprocesadores. Mach 3 dio lugar a varios esfuerzos para portar otras partes de sistemas operativos al microkernel, incluyendo Workplace OS de IBM y varios esfuerzos de Apple para crear una versión multiplataforma del Mac OS clásico . ^{[ 10 ]} Investigadores demostraron la compatibilidad para ejecutar aplicaciones DOS en un entorno Mach 3.0, tras trabajos anteriores que ejecutaban el Mac OS clásico y MultiFinder bajo Mach 2.5. ^{[ 11 ]} Un proyecto de investigación en Digital Equipment Corporation investigó la viabilidad de alojar OpenVMS sobre el kernel Mach 3 y creó una prueba de concepto con un subconjunto de las características de VMS. ^{[ 12 ]}

Mach se concibió originalmente como un reemplazo para el sistema UNIX monolítico clásico, y por ello incorporaba muchas ideas similares a las de UNIX. Por ejemplo, Mach proporcionaba un sistema de permisos y seguridad similar al del sistema de archivos de UNIX. Dado que el núcleo tenía privilegios (se ejecutaba en el espacio del núcleo ) sobre otros servidores y software del sistema operativo, era posible que programas defectuosos o maliciosos le enviaran comandos que dañaran el sistema, por lo que el núcleo verificaba la validez de cada mensaje. Además, la mayor parte de la funcionalidad del sistema operativo residía en programas del espacio de usuario, lo que implicaba la necesidad de que el núcleo otorgara a estos programas privilegios adicionales, como el acceso directo al hardware.

Algunas de las características más esotéricas de Mach también se basaban en este mismo mecanismo IPC. Por ejemplo, Mach podía soportar máquinas multiprocesador con facilidad. En un núcleo tradicional, se requiere un trabajo extenso para hacerlo reentrante o interrumpible , ya que los programas que se ejecutan en diferentes procesadores podrían llamar al núcleo simultáneamente. En Mach, los bits del sistema operativo están aislados en servidores, que pueden ejecutarse, como cualquier otro programa, en cualquier procesador. Si bien en teoría el núcleo de Mach también debería ser reentrante, en la práctica esto no representa un problema, ya que sus tiempos de respuesta son tan rápidos que simplemente puede esperar y atender las solicitudes por turnos. Mach también incluía un servidor que podía reenviar mensajes no solo entre programas, sino incluso a través de la red, un área de intenso desarrollo a finales de la década de 1980 y principios de la de 1990.

Desafortunadamente, el uso de IPC para casi todas las tareas tuvo un impacto significativo en el rendimiento. Las pruebas de rendimiento realizadas en hardware de 1997 mostraron que las implementaciones de UNIX de servidor único basadas en Mach 3.0 eran aproximadamente un 50 % más lentas que las implementaciones nativas de UNIX. ^{[ 13 ] [ 14 ]}

El estudio de la naturaleza exacta de los problemas de rendimiento reveló una serie de hechos interesantes. Uno de ellos fue que el IPC no era el problema: existía cierta sobrecarga asociada con el mapeo de memoria necesario para soportarlo, pero esto solo agregaba una pequeña cantidad de tiempo a la realización de una llamada. El resto, el 80% del tiempo empleado, se debía a tareas adicionales que el kernel ejecutaba en los mensajes. La principal entre estas era la verificación de derechos de puerto y la validez del mensaje. En pruebas de rendimiento en un 486 DX-50, una llamada al sistema UNIX estándar tardaba un promedio de 21 μs en completarse, mientras que la operación equivalente con Mach IPC promediaba 114 μs. Solo 18 μs de esto estaban relacionados con el hardware; el resto era el kernel de Mach ejecutando varias rutinas en el mensaje. ^{[ 15 ]} Dada una llamada al sistema que no hace nada, un viaje de ida y vuelta completo bajo BSD requeriría alrededor de 40 μs, mientras que en un sistema Mach en espacio de usuario tardaría poco menos de 500 μs.

Cuando Mach comenzó a usarse seriamente en las versiones 2.x, su rendimiento era más lento que el de los sistemas operativos monolíticos tradicionales, quizás hasta un 25 % inferior. ^{[ 1 ]} Sin embargo, este costo no se consideró particularmente preocupante, ya que el sistema también ofrecía soporte para multiprocesadores y fácil portabilidad. Muchos consideraron que este era un costo esperado y aceptable. Cuando Mach 3 intentó trasladar la mayor parte del sistema operativo al espacio de usuario, la sobrecarga aumentó aún más: las pruebas de rendimiento entre Mach y Ultrix en un MIPS R3000 mostraron una caída de rendimiento de hasta un 67 % en algunas cargas de trabajo. ^{[ 16 ]}

Por ejemplo, obtener la hora del sistema implica una llamada IPC al servidor de espacio de usuario que mantiene el reloj del sistema . El llamador primero entra en el kernel, lo que provoca un cambio de contexto y una asignación de memoria. El kernel luego verifica que el llamador tenga los permisos de acceso necesarios y que el mensaje sea válido. Si lo es, se produce otro cambio de contexto y asignación de memoria para completar la llamada al servidor de espacio de usuario. El proceso debe repetirse para devolver los resultados, lo que suma un total de cuatro cambios de contexto y asignaciones de memoria, más dos verificaciones de mensajes. Esta sobrecarga aumenta rápidamente con servicios más complejos, donde a menudo hay rutas de código que pasan por muchos servidores.

Esta no era la única fuente de problemas de rendimiento. Otro problema radicaba en la dificultad de gestionar la memoria correctamente cuando la memoria física se agotaba y era necesario realizar la paginación. En los sistemas operativos monolíticos tradicionales, los autores tenían experiencia directa sobre qué partes del núcleo llamaban a qué otras, lo que les permitía ajustar su paginador para evitar paginar código que estaba a punto de usarse. En Mach, esto no era posible porque el núcleo no tenía una idea clara de la estructura del sistema operativo. En su lugar, tuvieron que usar una única solución genérica, lo que agravó los problemas de rendimiento. Mach 3 intentó solucionar este problema proporcionando un paginador sencillo, basándose en paginadores del espacio de usuario para una mejor especialización. Sin embargo, esto tuvo poco efecto. En la práctica, cualquier beneficio que pudiera haber tenido se vio anulado por la costosa comunicación entre procesos (IPC) necesaria para su uso.

Otros problemas de rendimiento estaban relacionados con la compatibilidad de Mach con sistemas multiprocesador . Desde mediados de la década de 1980 hasta principios de la de 1990, el rendimiento de las CPU comerciales aumentó a un ritmo de aproximadamente el 60 % anual, pero la velocidad de acceso a la memoria creció solo un 7 % anual. Esto significó que el coste de acceso a la memoria aumentó enormemente durante este período, y dado que Mach se basaba en la redistribución de la memoria entre programas, cualquier fallo de caché ralentizaba las llamadas IPC.

La sobrecarga de comunicación entre procesos (IPC) es un problema importante para los sistemas Mach 3. El concepto de un sistema operativo multiservidor sigue siendo prometedor, aunque aún requiere investigación. Los desarrolladores deben tener cuidado de aislar el código en módulos que no se comuniquen entre servidores. Por ejemplo, la mayor parte del código de red se ubicaría en un solo servidor, minimizando así la IPC para las tareas de red habituales.

La mayoría de los desarrolladores se apegaron al concepto original de POE de un único servidor grande que proporcionaba la funcionalidad del sistema operativo. ^{[ 17 ]} Para facilitar el desarrollo, permitieron que el servidor del sistema operativo se ejecutara en el espacio de usuario o en el espacio del kernel. Esto les permitió desarrollar en el espacio de usuario y tener todas las ventajas de la idea original de Mach, y luego mover el servidor depurado al espacio del kernel para obtener un mejor rendimiento. Desde entonces, se han construido varios sistemas operativos utilizando este método, conocido como co-location , entre ellos Lites , MkLinux , OSF/1 y NeXTSTEP/OPENSTEP/macOS. El microkernel Chorus hizo de esto una característica del sistema básico, permitiendo elevar los servidores al espacio del kernel utilizando mecanismos integrados.

Mach 4 intentó solucionar estos problemas con una serie de mejoras más radicales. En particular, se descubrió que el código del programa generalmente no era modificable, por lo que los posibles fallos de escritura eran poco frecuentes. Por lo tanto, tenía sentido no mapear la memoria entre programas para la comunicación entre procesos (IPC), sino migrar el código del programa en uso al espacio local del programa. Esto dio lugar al concepto de "transbordadores" y, aparentemente, el rendimiento mejoró, pero los desarrolladores continuaron con el sistema en un estado semiutilizable. Mach 4 también introdujo primitivas de coubicación integradas, convirtiéndolas en parte del núcleo.

A mediados de la década de 1990, el trabajo en sistemas de microkernel estaba en gran medida estancado, aunque el mercado generalmente había creído que todos los sistemas operativos modernos estarían basados ​​en microkernel para la década de 1990. Los principales usos generalizados restantes del kernel Mach son macOS de Apple y su hermano iOS, que se ejecutan sobre un kernel Mach de Open Software Foundation híbrido muy modificado (OSFMK 7.3) llamado " XNU " ^{[ 18 ]} también utilizado en OSF/1. ^{[ 10 ]} En XNU, los sistemas de archivos, las pilas de red y las funciones de administración de procesos y memoria se implementan en el kernel; y el sistema de archivos, la red y algunas funciones de administración de procesos y memoria se invocan desde el modo de usuario a través de llamadas al sistema ordinarias en lugar de paso de mensajes; ^{[ 19 ] [ 20 ]} Los mensajes Mach de XNU se utilizan para la comunicación entre procesos en modo de usuario, y para algunas solicitudes del código en modo de usuario al kernel y del kernel a los servidores en modo de usuario.

Un análisis posterior demostró que el problema de rendimiento de IPC no era tan obvio como parecía. Recordemos que un solo lado de una llamada al sistema tardaba 20 μs en BSD ^{[ 3 ]} y 114 μs en Mach ejecutándose en el mismo sistema. ^{[ 2 ]} De los 114, 11 se debían al cambio de contexto, idéntico a BSD. ^{[ 14 ]} Otros 18 fueron utilizados por la MMU para mapear el mensaje entre el espacio de usuario y el espacio del kernel. ^{[ 3 ]} Esto suma solo 29 μs, más largo que una llamada al sistema tradicional, pero no mucho.

El resto, la mayor parte del problema real, se debía a que el núcleo realizaba tareas como comprobar el mensaje para los derechos de acceso al puerto. ^{[ 6 ]} Si bien parecería que esto es una importante preocupación de seguridad, de hecho, solo tiene sentido en un sistema tipo UNIX. Por ejemplo, un sistema operativo de un solo usuario que ejecuta un teléfono móvil o un robot podría no necesitar ninguna de estas características, y este es precisamente el tipo de sistema donde el sistema operativo de selección de Mach sería más valioso. Del mismo modo, Mach causaba problemas cuando el sistema operativo movía la memoria, otra tarea que solo tiene sentido si el sistema tiene más de un espacio de direcciones. DOS y el primer Mac OS tienen un único espacio de direcciones grande compartido por todos los programas, por lo que en estos sistemas el mapeo no proporcionaba ningún beneficio.

Estas conclusiones llevaron a una serie de microkernels de segunda generación, que redujeron aún más la complejidad del sistema y colocaron casi toda la funcionalidad en el espacio de usuario. Por ejemplo, el kernel L4 (versión 2) incluye solo siete llamadas al sistema y usa 12k de memoria, ^{[ 3 ]} mientras que Mach 3 incluye alrededor de 140 funciones y usa alrededor de 330k de memoria. ^{[ 3 ]} Las llamadas IPC bajo L4 en un 486DX-50 tardan solo 5μs, ^{[ 20 ]} más rápido que una llamada al sistema UNIX en el mismo sistema, y ​​más de 20 veces más rápido que Mach. Por supuesto, esto ignora el hecho de que L4 no maneja permisos ni seguridad; pero al dejar esto a los programas del espacio de usuario, estos pueden seleccionar la sobrecarga que necesiten.

Las posibles mejoras de rendimiento de L4 se ven atenuadas por el hecho de que las aplicaciones en el espacio de usuario a menudo tendrán que proporcionar muchas de las funciones que antes soportaba el kernel. Para probar el rendimiento de extremo a extremo, se comparó MkLinux en modo de ubicación conjunta con una versión L4 que se ejecutaba en el espacio de usuario. L4 añadió una sobrecarga de entre el 5 % y el 10 %, ^{[ 14 ]} en comparación con el 29 % de Mach. ^{[ 14 ]}