Mach ( / m ɑː k / ) [1] es un núcleo desarrollado en la Universidad Carnegie Mellon por Richard Rashid y Avie Tevanian para apoyar la investigación de sistemas operativos , principalmente computación distribuida y paralela . Mach se considera a menudo uno de los primeros ejemplos de micronúcleo . Sin embargo, no todas las versiones de Mach son microkernels. Los derivados de Mach son la base del kernel del sistema operativo en GNU Hurd y del kernel XNU de Apple utilizado en macOS , iOS , iPadOS , tvOS y watchOS .
El proyecto en Carnegie Mellon se desarrolló entre 1985 y 1994, [2] terminando con Mach 3.0, que es un verdadero microkernel . Mach fue desarrollado como reemplazo del kernel en la versión BSD de Unix , por lo que no sería necesario diseñar ningún nuevo sistema operativo en torno a él. Mach y sus derivados existen en varios sistemas operativos comerciales. Estos incluyen todos los que utilizan el kernel del sistema operativo XNU, que incorpora un Mach anterior sin microkernel como componente principal. El sistema de gestión de memoria virtual Mach también fue adoptado en 4.4BSD por los desarrolladores de BSD en CSRG , [3] y aparece en sistemas Unix modernos derivados de BSD como FreeBSD .
Mach es el sucesor lógico del núcleo Accent de Carnegie Mellon . El desarrollador principal del proyecto Mach, Richard Rashid, trabaja en Microsoft desde 1991; Fundó la división de investigación de Microsoft . Otro de los desarrolladores originales de Mach, Avie Tevanian, fue anteriormente jefe de software en NeXT y luego director de tecnología de software en Apple Inc. hasta marzo de 2006. [4] [2]
Los desarrolladores tuvieron que ir en bicicleta a almorzar a través de los charcos de barro lluviosos de Pittsburgh, y Tevanian bromeó diciendo que la palabra "muck" podría formar un backronym 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 lo deletreó sino que simplemente pronunció: IPA: [mʌk] que, según el alfabeto italiano , Escribió como Mach. A Rashid le gustó tanto la ortografía "Mach" de Giuse que prevaleció. [6] : 103
Un concepto clave en el sistema operativo Unix original fue la idea de una tubería . Una tubería era una abstracción que permitía mover datos como un flujo no estructurado de bytes de un programa a otro. Usando tuberías, los usuarios (o programadores) podrían vincular múltiples programas para completar tareas, alimentando datos a través de varios programas pequeños a su vez. Esto contrastaba con los sistemas operativos típicos de la época, que requerían un único programa grande que pudiera manejar toda la tarea o, alternativamente, usaban archivos para pasar datos, lo que consumía mucho tiempo y recursos.
Se construyeron tuberías sobre el sistema de entrada/salida subyacente . Este sistema, a su vez, se basó en un modelo en el que se esperaba que los conductores se "bloquearan" periódicamente mientras esperaban que se completaran las tareas. Por ejemplo, un controlador de impresora podría enviar una línea de texto a una impresora de líneas y luego no tener nada que hacer hasta que la impresora complete la impresión de esa línea. En este caso, el controlador indicaría que estaba bloqueado y el sistema operativo permitiría que se ejecutara algún otro programa hasta que la impresora indicara que estaba 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, naturalmente se bloqueaba. Normalmente esto haría que el programa consumidor se ejecutara, vaciando la tubería nuevamente. A diferencia de un archivo, donde se debe leer o escribir todo el archivo antes de que el siguiente programa pueda usarlo, las tuberías hicieron que el movimiento de datos entre múltiples programas se produjera de forma gradual sin ninguna intervención del programador.
Sin embargo, la implementación de canalizaciones en los buffers de memoria obligó a copiar los datos de un programa a otro, una operación que requiere mucho tiempo y recursos. Esto hizo que el concepto de canalización no fuera adecuado para tareas en las que se necesitaba 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 las funciones principales se escribieron en un único programa grande. Cuando se agregaron al sistema operativo nuevas funciones, como las redes de computadoras , el tamaño y la complejidad del núcleo también crecieron.
Las tuberías Unix ofrecían un sistema conceptual que podía usarse para construir soluciones arbitrariamente complejas a partir de pequeños programas interactivos. Estos programas más pequeños eran más fáciles de desarrollar y mantener y tenían interfaces bien definidas que simplificaban la programación y la depuración. Estas cualidades son aún más valiosas para los controladores de dispositivos, donde el tamaño pequeño y el rendimiento sin errores son extremadamente importantes. Existía un fuerte deseo de modelar el propio núcleo sobre la misma base de pequeños programas interactivos.
Uno de los primeros sistemas en utilizar un sistema similar a una tubería como base del sistema operativo fue el kernel Aleph desarrollado en la Universidad de Rochester . Esto introdujo el concepto de puertos , que eran esencialmente una implementación de memoria compartida . En Aleph, el núcleo en sí se redujo a proporcionar acceso al hardware, incluida la memoria y los puertos, mientras que los programas convencionales que usaban el sistema de puertos implementaban todo el comportamiento, desde los controladores de dispositivos hasta los programas de usuario. Este concepto redujo en gran medida el tamaño del kernel y permitió a los usuarios experimentar con diferentes controladores simplemente cargándolos y conectándolos en tiempo de ejecución. Esto alivió enormemente los problemas al desarrollar un nuevo código del sistema operativo, que de otro modo generalmente requerí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 minicomputadoras Data General Eclipse y estaba estrechamente vinculado a ellas. Esta máquina estaba lejos de ser ideal, ya que requería copiar memoria entre programas, lo que implicaba una sobrecarga de rendimiento considerable. También era bastante caro. Sin embargo, Aleph demostró que el sistema básico era sólido y continuó demostrando la agrupación de computadoras copiando la memoria a través de una de las primeras interfaces Ethernet .
Por esta época estaba llegando al mercado una nueva generación de procesadores centrales (CPU), que ofrecían espacios de direcciones de 32 bits y soporte (inicialmente opcional) para una unidad de gestión de memoria (MMU). La MMU manejó las instrucciones necesarias para implementar un sistema de memoria virtual realizando un seguimiento de qué páginas de memoria estaban utilizando varios programas. Esto ofreció una nueva solución al concepto de puerto, utilizando el mecanismo de copia en escritura proporcionado por el sistema de memoria virtual. En lugar de copiar datos entre programas, todo lo que había que enviar eran los datos necesarios para indicarle a la MMU que proporcionara acceso a la misma memoria. Este sistema implementaría el sistema de comunicaciones entre procesos con un rendimiento dramáticamente mayor.
Este concepto fue retomado por Carnegie-Mellon, quien adaptó Aleph para la estación de trabajo PERQ y lo implementó mediante copia en escritura. La adaptación fue exitosa, pero el kernel Accent resultante tuvo un uso práctico limitado porque no ejecutaba el software existente. Además, Accent estaba tan estrechamente vinculado a PERQ como Aleph lo estaba al Eclipse.
El cambio más importante entre estos núcleos experimentales y Mach fue la decisión de crear una versión del núcleo 4.2BSD existente reimplementado en los conceptos de paso de mensajes de Accent. Un kernel de este tipo sería compatible binariamente con el software BSD existente, lo que haría que el sistema fuera inmediatamente útil para el uso diario y al mismo tiempo seguiría siendo una plataforma experimental útil. Además, el nuevo kernel estaría diseñado desde el principio para soportar múltiples arquitecturas de procesador, permitiendo incluso la construcción de clusters heterogéneos. Para que el sistema funcione lo más rápido posible, el sistema se implementaría comenzando con el código BSD existente y reimplementándolo poco a poco como programas basados en comunicación entre procesos (basados en IPC). Por lo tanto, Mach comenzaría como un sistema monolítico similar a los sistemas UNIX existentes y evolucionaría más hacia el concepto de microkernel con el tiempo. [4]
Mach comenzó en gran medida como un esfuerzo por producir un Accent altamente portátil, basado en UNIX y claramente definido. El resultado es una breve lista de conceptos genéricos: [7] [8]
Mach desarrolló los conceptos IPC de Accent, pero hizo que el sistema fuera mucho más parecido a UNIX por naturaleza, incluso capaz de ejecutar programas UNIX con poca o ninguna modificación. Para ello, Mach introdujo el concepto de puerto , que representa cada punto final de un IPC bidireccional. Los puertos tenían seguridad y derechos como archivos en UNIX, lo que permitía aplicarles un modelo de protección muy similar a UNIX. Además, Mach permitió que cualquier programa manejara privilegios que normalmente se otorgarían solo al sistema operativo, para permitir que los programas del espacio de usuario manejaran cosas como interactuar con el hardware.
Bajo Mach, y al igual que UNIX, el sistema operativo vuelve a ser principalmente una colección de utilidades. Al igual que UNIX, Mach mantiene el concepto de controlador para manejar el hardware. Por lo tanto, todos los controladores para el hardware actual deben incluirse en el microkernel. Otras arquitecturas basadas en una capa de abstracción de hardware o exokernels podrían sacar los controladores del microkernel.
La principal diferencia con UNIX es que en lugar de que las utilidades manejen archivos, pueden manejar cualquier "tarea". Se sacó más código del sistema operativo del kernel y se trasladó al espacio del usuario, lo que dio como resultado un kernel mucho más pequeño y el surgimiento del término microkernel . A diferencia de los sistemas tradicionales, en Mach un proceso o "tarea" puede constar de varios subprocesos. Si bien esto es común en los sistemas modernos, Mach fue el primer sistema en definir tareas e hilos de esta manera. El trabajo del kernel se redujo de ser esencialmente el sistema operativo a mantener las "utilidades" y programar su acceso al hardware.
La existencia de puertos y el uso de IPC es quizás la diferencia más fundamental entre Mach y los kernels tradicionales. En UNIX, llamar al kernel consiste en una operación denominada llamada al sistema o trampa . El programa utiliza una biblioteca para colocar datos en una ubicación conocida en la memoria y luego provoca una falla , un tipo de error. Cuando un sistema se inicia por primera vez, su núcleo está configurado para ser el "controlador" de todas las fallas; por lo tanto, cuando un programa causa una falla, el núcleo toma el control, examina la información que se le pasa y luego ejecuta las instrucciones.
Bajo Mach, se utilizó el sistema IPC para esta función. Para llamar a la funcionalidad del sistema, un programa solicitaría al kernel acceso a un puerto y luego usaría el sistema IPC para enviar mensajes a ese puerto. Aunque enviar un mensaje requiere una llamada al sistema, así como una solicitud de funcionalidad del sistema en otros sistemas requiere una llamada al sistema, bajo Mach enviar el mensaje es prácticamente todo lo que hace el núcleo; manejar la solicitud real dependería de algún otro programa.
El soporte de subprocesos y concurrencia se benefició del paso de mensajes con mecanismos IPC, ya que las tareas ahora consistían en múltiples subprocesos de código que Mach podía congelar y descongelar durante el manejo de mensajes. Esto permitió que el sistema se distribuyera en múltiples procesadores, ya sea usando memoria compartida directamente como en la mayoría de los mensajes Mach, o agregando código para copiar el mensaje a otro procesador si fuera necesario. En un kernel tradicional esto es difícil de implementar; el sistema debe asegurarse de que diferentes programas no intenten escribir en la misma memoria desde diferentes procesadores. Sin embargo, los puertos Mach y su proceso de acceso a la memoria lo hacen bien definido y fácil de implementar, y se convirtieron en ciudadanos de primera clase en ese sistema.
Inicialmente, el sistema IPC tuvo problemas de rendimiento, por lo que se desarrollaron algunas estrategias para minimizar el impacto. Al igual que su predecesor, Accent, Mach utilizó un único mecanismo de memoria compartida para pasar físicamente el mensaje de un programa a otro. Copiar físicamente el mensaje sería demasiado lento, por lo que Mach depende de la unidad de administración de memoria (MMU) de la máquina para asignar rápidamente los datos de un programa a otro. Sólo si los datos están escritos, tendrían que copiarse físicamente, un proceso llamado " copia en escritura ".
El kernel también verificaba la validez de los mensajes, para evitar que los datos incorrectos bloquearan uno de los muchos programas que componen el sistema. Los puertos se modelaron deliberadamente según los conceptos del sistema de archivos UNIX. Esto permitió al usuario encontrar puertos utilizando conceptos de navegación del sistema de archivos existentes, así como asignar derechos y permisos como lo harían en el sistema de archivos.
El desarrollo bajo un sistema así sería más fácil. El código en el que se está trabajando no sólo existiría en un programa tradicional que podría construirse utilizando herramientas existentes, sino que también podría iniciarse, depurarse y finalizarse utilizando las mismas herramientas. Con un monokernel, un error en el código nuevo haría que toda la máquina quedara fuera de servicio y requeriría un reinicio, mientras que en Mach esto sólo requeriría que se reiniciara el programa. Además, el usuario podría adaptar el sistema para incluir o excluir cualquier característica que requiera. Dado que el sistema operativo era simplemente una colección de programas, podían agregar o eliminar partes simplemente ejecutándolas o eliminándolas como lo harían con cualquier otro programa.
Finalmente, bajo Mach, todas estas características fueron diseñadas deliberadamente para ser extremadamente neutrales en cuanto a plataforma. Para citar un texto sobre Mach:
Sin embargo, existen varias desventajas. Una relativamente mundana es que no está claro cómo encontrar puertos. Bajo UNIX, este problema se resolvió con el tiempo cuando los programadores acordaron una serie de ubicaciones "bien conocidas" en el sistema de archivos para cumplir diversas funciones. Si bien este mismo enfoque también funcionó para los puertos de Mach, bajo Mach se suponía que el sistema operativo era mucho más fluido, con puertos apareciendo y desapareciendo todo el tiempo. Sin algún mecanismo para encontrar puertos y los servicios que representan, gran parte de esta flexibilidad se perdería.
Inicialmente, Mach se alojó como código adicional escrito directamente en el kernel 4.2BSD existente, lo que permitió al equipo trabajar en el sistema mucho antes de que estuviera completo. El trabajo comenzó con el sistema de puerto/IPC Accent ya funcional y pasó a otras partes clave del sistema operativo: tareas, subprocesos y memoria virtual. A medida que se completaron algunas partes, se reescribieron varias partes del sistema BSD para llamarlas a Mach, y también se realizó un cambio a 4.3BSD durante este proceso.
En 1986, el sistema estaba completo hasta el punto de poder funcionar por sí solo en el DEC VAX . Aunque se hizo poco valor práctico, se logró el objetivo de fabricar un micronúcleo. A esto pronto le siguieron versiones para IBM RT PC y para estaciones de trabajo basadas en Sun Microsystems 68030 , lo que demuestra la portabilidad del sistema. En 1987, la lista incluía las máquinas Encore Multimax y Sequent Balance , probando la capacidad de Mach para ejecutarse en sistemas multiprocesador. Ese año se realizó una versión pública 1 y la versión 2 siguió al año siguiente.
Durante todo este tiempo, la promesa de un micronúcleo "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 dio como resultado un kernel que en realidad era más grande que el UNIX en el que se basaba. La idea, sin embargo, era mover la capa UNIX fuera del kernel al espacio del usuario, donde podría ser más fácil trabajar en ella e incluso reemplazarla por completo. Desafortunadamente, el rendimiento resultó ser un problema importante y se realizaron una serie de cambios arquitectónicos para resolverlo. Los difíciles problemas de licencias de UNIX también atormentaban a los investigadores, por lo que este esfuerzo inicial para proporcionar un entorno de sistema similar a UNIX sin licencia continuó encontrando uso, hasta bien avanzado el desarrollo de Mach.
El Mach 3 resultante se lanzó en 1990 y generó un gran interés. Un pequeño equipo había construido Mach y lo había portado a varias plataformas, incluidos complejos sistemas multiprocesador que estaban causando serios problemas a los núcleos de estilo antiguo. Esto generó un interés considerable en el mercado comercial, donde varias empresas estaban considerando cambiar las plataformas de hardware. Si el sistema existente pudiera adaptarse para ejecutarse en Mach, parecería que sería fácil 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 estaban investigando Mach 3. También se seleccionó Mach 2.5 para el sistema NeXTSTEP y varios proveedores comerciales de multiprocesadores. Mach 3 dio lugar a una serie de esfuerzos para portar otras partes de sistemas operativos para el microkernel, incluido Workplace OS de IBM y varios esfuerzos de Apple para crear una versión multiplataforma del Mac OS clásico . [10] Los investigadores demostraron la compatibilidad con la ejecución de aplicaciones DOS en un entorno Mach 3.0, siguiendo un trabajo anterior ejecutando el Mac OS clásico y MultiFinder en Mach 2.5. [11]
Originalmente, Mach estaba destinado a ser un reemplazo del UNIX monolítico clásico y, por esta razón, contenía muchas ideas similares a UNIX. Por ejemplo, Mach utilizó un sistema de permisos y seguridad basado en el sistema de archivos de UNIX. Dado que el kernel tenía privilegios (se ejecutaba en el espacio del kernel ) sobre otros servidores y software del sistema operativo, era posible que programas maliciosos o que funcionaran mal le enviaran comandos que causarían daños al sistema y, por esta razón, el kernel verificaba la validez de cada mensaje. . Además, la mayor parte de la funcionalidad del sistema operativo debía ubicarse en programas del espacio de usuario, por lo que esto significaba que debía haber alguna forma para que el núcleo otorgara a estos programas privilegios adicionales, por ejemplo, acceder directamente 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 pudo admitir máquinas multiprocesador con facilidad. En un kernel tradicional es necesario realizar un trabajo extenso para hacerlo reentrante o interrumpible , ya que los programas que se ejecutan en diferentes procesadores podrían llamar al kernel al mismo tiempo. En Mach, los bits del sistema operativo están aislados en servidores, que pueden ejecutarse, como cualquier otro programa, en cualquier procesador. Aunque en teoría el núcleo Mach también tendría que ser reentrante, en la práctica esto no es un problema porque sus tiempos de respuesta son tan rápidos que simplemente puede esperar y atender solicitudes por turno. Mach también incluía un servidor que podía reenviar mensajes no sólo entre programas, sino incluso a través de la red, lo cual fue un área de intenso desarrollo a finales de los 80 y principios de los 90.
Desafortunadamente, el uso de IPC para casi todas las tareas resultó tener un impacto grave en el rendimiento. Los puntos de referencia en hardware de 1997 mostraron que las implementaciones de servidor único UNIX basadas en Mach 3.0 eran aproximadamente un 50% más lentas que las de UNIX nativo. [12] [13]
El estudio de la naturaleza exacta de los problemas de desempeño arrojó una serie de hechos interesantes. Una era que el IPC en sí no era el problema: había cierta sobrecarga asociada con el mapeo de memoria necesario para soportarlo, pero esto agregaba sólo una pequeña cantidad de tiempo para realizar una llamada. El resto, el 80% del tiempo invertido, se debió a tareas adicionales que el kernel estaba ejecutando en los mensajes. El principal de ellos fue la verificación de derechos de puerto y la validez de los mensajes. En las pruebas comparativas en un 486 DX-50, una llamada al sistema UNIX estándar tardó un promedio de 21 μs en completarse, mientras que la operación equivalente con Mach IPC promedió 114 μs. Sólo 18 μs de esto estaban relacionados con el hardware; el resto era el núcleo Mach ejecutando varias rutinas en el mensaje. [14] 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 tomaría poco menos de 500 μs.
Cuando Mach se utilizó seriamente por primera vez en las versiones 2.x, el rendimiento era más lento que el de los sistemas operativos monolíticos tradicionales, quizás hasta un 25%. [1] Sin embargo, este costo no se consideró particularmente preocupante porque el sistema también ofrecía soporte multiprocesador y fácil portabilidad. Muchos sintieron que este era un costo esperado y aceptable a pagar. Cuando Mach 3 intentó mover la mayor parte del sistema operativo al espacio del usuario, la sobrecarga se hizo aún mayor: los puntos de referencia entre Mach y Ultrix en un MIPS R3000 mostraron un impacto en el rendimiento de hasta el 67% en algunas cargas de trabajo. [15]
Por ejemplo, obtener la hora del sistema implica una llamada IPC al servidor de espacio de usuario que mantiene el reloj del sistema . La persona que llama primero entra en el kernel, lo que provoca un cambio de contexto y un mapeo de memoria. Luego, el kernel verifica que la persona que llama tenga los derechos de acceso requeridos y que el mensaje sea válido. Si es así, hay otro cambio de contexto y asignación de memoria para completar la llamada al servidor de espacio de usuario. Luego, el proceso debe repetirse para devolver los resultados, sumando un total de cuatro cambios de contexto y asignaciones de memoria, además de dos verificaciones de mensajes. Esta sobrecarga se agrava rápidamente con servicios más complejos, donde a menudo hay rutas de código que pasan por muchos servidores.
Esta no fue la única fuente de problemas de rendimiento. Otro se centró en los problemas de tratar de manejar la memoria adecuadamente cuando la memoria física se agotaba y era necesario realizar una paginación. En los sistemas operativos monolíticos tradicionales, los autores tenían experiencia directa con qué partes del núcleo llamaban a otras, lo que les permitía ajustar su buscapersonas para evitar paginar el código que estaba a punto de usarse. Con Mach esto no era posible porque el núcleo no tenía idea real de en qué consistía el sistema operativo. En lugar de ello, tuvieron que utilizar una solución única que sirviera para todos, lo que se sumó a los problemas de rendimiento. Mach 3 intentó solucionar este problema proporcionando un buscapersonas simple, basándose en buscapersonas en el espacio del usuario para una mejor especialización. Pero esto resultó tener poco efecto. En la práctica, cualquier beneficio que tuviera fue anulado por el costoso IPC necesario para llamarlo.
Otros problemas de rendimiento estaban relacionados con el soporte de Mach para sistemas multiprocesador . Desde mediados de la década de 1980 hasta principios de la de 1990, el rendimiento de las CPU comerciales creció a un ritmo de alrededor del 60% al año, pero la velocidad de acceso a la memoria creció sólo un 7% al año. Esto significó que el costo de acceder a la memoria creció enormemente durante este período, y dado que Mach se basaba en mapear la memoria entre programas, cualquier "fallo de caché" hacía que las llamadas IPC fueran lentas.
La sobrecarga de IPC es un problema importante para los sistemas Mach 3. Sin embargo, el concepto de un sistema operativo multiservidor sigue siendo prometedor, aunque todavía requiere algo de investigación. Los desarrolladores deben tener cuidado de aislar el código en módulos que no llamen de un servidor a otro. Por ejemplo, la mayor parte del código de red se colocaría en un único servidor, minimizando así el IPC para las tareas de red normales.
En cambio, la mayoría de los desarrolladores se apegaron al concepto POE original de un único servidor grande que proporciona la funcionalidad del sistema operativo. [16] Para facilitar el desarrollo, permitieron que el servidor del sistema operativo se ejecutara en el espacio del usuario o en el espacio del kernel. Esto les permitió desarrollarse en el espacio del 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 coubicación , entre ellos Lites , MkLinux , OSF/1 y NeXTSTEP/OPENSTEP/macOS. El microkernel Chorus hizo de esto una característica del sistema básico, permitiendo que los servidores se elevaran al espacio del kernel usando mecanismos integrados.
Mach 4 intentó solucionar estos problemas, esta vez con un conjunto de actualizaciones más radicales. En particular, se descubrió que el código del programa normalmente no se podía escribir, por lo que los posibles resultados debidos a la copia en escritura eran raros. Por lo tanto, tenía sentido no mapear la memoria entre programas para IPC, sino migrar el código del programa que se está utilizando al espacio local del programa. Esto llevó al concepto de "lanzaderas" y parecía que el rendimiento había mejorado, pero los desarrolladores continuaron con el sistema en un estado semiutilizable. Mach 4 también introdujo primitivas de coubicación integradas, convirtiéndolo en parte del propio núcleo.
A mediados de la década de 1990, el trabajo en sistemas de microkernel estaba en gran medida estancado, aunque el mercado había creído en general que todos los sistemas operativos modernos estarían basados en microkernel en la década de 1990. Los principales usos generalizados que quedan del kernel Mach son macOS de Apple y su hermano iOS, que se ejecutan sobre un kernel Mach híbrido de Open Software Foundation (OSFMK 7.3) muy modificado llamado " XNU " [17] también utilizado en OSF/1. [10] En XNU, los sistemas de archivos, las pilas de red y las funciones de gestión de procesos y memoria se implementan en el kernel; y el sistema de archivos, las redes y algunas funciones de gestión de procesos y memoria se invocan desde el modo de usuario mediante llamadas ordinarias al sistema en lugar de pasar mensajes; [18] [19] Los mensajes Mach de XNU se utilizan para la comunicación entre procesos en modo de usuario y para algunas solicitudes desde el código en modo de usuario al kernel y desde el kernel a los servidores en modo de usuario.
Un análisis más detallado demostró que el problema de rendimiento de la IPC no era tan obvio como parecía. Recuerde que un solo lado de una llamada al sistema tomó 20 μs en BSD [3] y 114 μs en Mach ejecutándose en el mismo sistema. [2] De los 114, 11 se debieron al cambio de contexto, idéntico a BSD. [13] La MMU utilizó 18 adicionales para mapear el mensaje entre el espacio de usuario y el espacio del kernel. [3] Esto suma solo 29 μs, más tiempo que una llamada al sistema tradicional, pero no mucho.
El resto, la mayor parte del problema real, se debió a que el kernel realizaba tareas como verificar el mensaje para obtener derechos de acceso al puerto. [6] Si bien parecería que esto es una preocupación de seguridad importante, de hecho, sólo tiene sentido en un sistema tipo UNIX. Por ejemplo, un sistema operativo de usuario único que ejecute un teléfono celular o un robot podría no necesitar ninguna de estas características, y este es exactamente el tipo de sistema donde el sistema operativo de Mach sería más valioso. Asimismo, Mach causaba problemas cuando el sistema operativo movía la memoria, otra tarea que sólo tiene sentido si el sistema tiene más de un espacio de direcciones. DOS y los primeros Mac OS tienen un único espacio de direcciones grande compartido por todos los programas, por lo que en estos sistemas el mapeo no proporcionó ningún beneficio.
Estos descubrimientos llevaron a una serie de micronúcleos de segunda generación, que redujeron aún más la complejidad del sistema y colocaron casi todas las funciones en el espacio del 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 toman solo 5 μs, [19] 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 en manos de los programas del espacio de usuario, pueden seleccionar tanta o tan poca sobrecarga como necesiten.
Las posibles ganancias de rendimiento de L4 se ven atenuadas por el hecho de que las aplicaciones del espacio de usuario a menudo tendrán que proporcionar muchas de las funciones que antes soportaba el núcleo. Para probar el rendimiento de un extremo a otro, se comparó MkLinux en modo compartido con un puerto L4 que se ejecuta en el espacio del usuario. L4 agregó entre un 5% y un 10% de gastos generales, [13] en comparación con el 29% de Mach. [13]
La siguiente es una lista de kernels de sistemas operativos derivados de Mach y sistemas operativos con kernels derivados de Mach: