ماخ (نواة)

ركب المطورون دراجاتهم الهوائية لتناول الغداء عبر برك الطين في بيتسبرغ الممطرة، ومازح تيفانيان قائلاً إن كلمة "muck" (وحل) يمكن أن تشكل اختصارًا عكسيًا لنواة الاتصال متعددة المستخدمين (أو متعددة المعالجات العالمية). سأل المهندس الإيطالي داريو جيوز ^{[ 5 ]} قائد المشروع ريك رشيد عن الاسم الحالي للمشروع، فتلقى إجابة "MUCK" (وإن لم تُكتب الكلمة كاملة، بل نُطقت فقط /mʌk / ) . ووفقًا للأبجدية الإيطالية ، كتب رشيد "Mach" (ماخ). أعجب رشيد تهجئة جيوز "Mach" لدرجة أنها اعتُمدت. ^{[ 6 ] : 103}

يُعدّ مفهوم الأنابيب أحد المفاهيم الأساسية في نظام التشغيل يونكس الأصلي . فالأنابيب عبارة عن تجريد يسمح بنقل البيانات كتدفق غير منظم من البايتات بين البرامج. وباستخدام الأنابيب، يستطيع المستخدمون ربط برامج متعددة لإنجاز مهام محددة، وذلك بتمرير البيانات عبر عدة برامج صغيرة متتالية. وهذا يختلف عن أنظمة التشغيل التقليدية في ذلك الوقت، التي كانت تتطلب برنامجًا واحدًا كبيرًا قادرًا على إنجاز المهمة بأكملها، أو كانت تستخدم الملفات لنقل البيانات، وهو ما كان يستهلك موارد النظام ويستغرق وقتًا طويلاً.

بُنيت الأنابيب على نظام الإدخال/الإخراج الأساسي . ويعتمد هذا النظام بدوره على نموذج يُتوقع فيه من برامج التشغيل "التوقف" دوريًا أثناء انتظارها اكتمال المهام. على سبيل المثال، قد يُرسل برنامج تشغيل طابعة سطرًا نصيًا إلى طابعة خطية ، ثم لا يكون لديه ما يفعله حتى تنتهي الطابعة من طباعة ذلك السطر. في هذه الحالة، يُشير برنامج التشغيل إلى أنه متوقف، ويسمح نظام التشغيل لبرنامج آخر بالعمل حتى تُشير الطابعة إلى استعدادها لمزيد من البيانات. في نظام الأنابيب، كان المورد المحدود هو الذاكرة، وعندما يملأ أحد البرامج الذاكرة المُخصصة للأنبوب، فإنه سيتوقف تلقائيًا. عادةً ما يؤدي هذا إلى تشغيل البرنامج المُستهلك، مما يُفرغ الأنبوب مرة أخرى. على عكس الملف، حيث يجب قراءة الملف بالكامل أو الكتابة إليه قبل أن يتمكن البرنامج التالي من استخدامه، جعلت الأنابيب نقل البيانات بين برامج متعددة يتم بشكل تدريجي دون أي تدخل من المبرمج.

أدى استخدام الأنابيب في مخازن الذاكرة إلى إجبار النظام على نسخ البيانات من برنامج لآخر، وهي عملية تستغرق وقتًا طويلاً وتستهلك موارد كثيرة. هذا جعل مفهوم الأنابيب غير مناسب للمهام التي تتطلب سرعة استجابة عالية أو زمن استجابة منخفض، كما هو الحال في معظم برامج تشغيل الأجهزة . ولذلك، كُتبت نواة نظام التشغيل ومعظم وظائفه الأساسية في برنامج واحد كبير. وعندما أُضيفت وظائف جديدة، مثل شبكات الحاسوب ، إلى نظام التشغيل، ازداد حجم النواة وتعقيدها أيضًا.

وفرت أنابيب يونكس نظامًا مفاهيميًا يُمكن استخدامه لبناء حلول بالغة التعقيد من خلال برامج صغيرة متعاونة. تميزت هذه البرامج الأصغر حجمًا بسهولة تطويرها وصيانتها، فضلًا عن واجهاتها الواضحة التي سهّلت البرمجة وتصحيح الأخطاء. وتزداد أهمية هذه الميزات في برامج تشغيل الأجهزة، حيث يُعدّ صغر الحجم والأداء الخالي من الأخطاء أمرًا بالغ الأهمية. وقد برزت رغبة قوية في تصميم نواة النظام على نفس أساس البرامج الصغيرة المتعاونة.

كان نظام Aleph، الذي طُوّر في جامعة روتشستر ، من أوائل الأنظمة التي استخدمت نظامًا شبيهًا بالأنابيب لدعم نظام التشغيل . وقد قدّم هذا النظام مفهوم المنافذ، التي كانت في جوهرها تطبيقًا للذاكرة المشتركة . في Aleph، اقتصر دور النواة على توفير الوصول إلى المكونات المادية، بما في ذلك الذاكرة والمنافذ، بينما تولّت البرامج التقليدية التي تستخدم نظام المنافذ تنفيذ جميع الوظائف، بدءًا من برامج تشغيل الأجهزة وصولًا إلى برامج المستخدم. قلّل هذا المفهوم حجم النواة بشكل كبير، وسمح للمستخدمين بتجربة برامج تشغيل مختلفة ببساطة عن طريق تحميلها وربطها معًا أثناء التشغيل. وقد سهّل هذا الأمر بشكل كبير عملية تطوير أكواد جديدة لنظام التشغيل، والتي كانت تتطلب في السابق إعادة تشغيل الجهاز. عُرف المفهوم العام للنواة الصغيرة وبرامج التشغيل الخارجية باسم النواة المصغّرة.

تم تطبيق نظام أليف على حواسيب إكليبس المصغرة من شركة داتا جنرال، وكان مرتبطًا بها ارتباطًا وثيقًا. لم يكن هذا الجهاز مثاليًا، إذ كان يتطلب نسخ الذاكرة بين البرامج، مما أدى إلى زيادة ملحوظة في استهلاك موارد النظام. كما كان مكلفًا للغاية. مع ذلك، أثبت أليف سلامة النظام الأساسي، وواصل مسيرته ليُظهر إمكانية تجميع الحواسيب عن طريق نسخ الذاكرة عبر واجهة إيثرنت بدائية .

في ذلك الوقت تقريبًا، ظهر جيل جديد من المعالجات المركزية (CPUs) في الأسواق، مزودًا بمساحة عناوين 32 بت ودعم (اختياري في البداية) لوحدة إدارة الذاكرة (MMU). تولت وحدة إدارة الذاكرة معالجة التعليمات اللازمة لتنفيذ نظام الذاكرة الافتراضية من خلال تتبع صفحات الذاكرة المستخدمة من قِبل البرامج المختلفة. وقدّم هذا حلًا جديدًا لمفهوم المنافذ، باستخدام آلية النسخ عند الكتابة (COW) التي يوفرها نظام الذاكرة الافتراضية. فبدلًا من نسخ البيانات بين البرامج، كان المطلوب فقط توجيه وحدة إدارة الذاكرة لتوفير الوصول إلى نفس الذاكرة. وقد ساهم هذا النظام في تنفيذ نظام الاتصالات بين العمليات (IPC) بأداء أعلى بكثير.

تم تبني هذا المفهوم في جامعة كارنيجي ميلون، حيث قاموا بتكييف نظام Aleph لمحطة عمل PERQ ونفذوه باستخدام تقنية النسخ عند الكتابة. نجحت عملية النقل، لكن نواة Accent الناتجة كانت محدودة الفائدة العملية لعدم قدرتها على تشغيل البرامج الموجودة. علاوة على ذلك، كان نظام Accent مرتبطًا ارتباطًا وثيقًا بنظام PERQ تمامًا كما كان نظام Aleph مرتبطًا بنظام Eclipse.

كان التغيير الرئيسي بين هذه النوى التجريبية ونظام Mach هو قرار إعادة تنفيذ نسخة من نواة 4.2BSD الحالية باستخدام مفاهيم تمرير الرسائل في Accent. ستكون هذه النواة متوافقة ثنائيًا مع برامج BSD الحالية ، مما يجعل النظام متاحًا للاستخدام اليومي فورًا مع الحفاظ على كونه منصة تجريبية مفيدة. بالإضافة إلى ذلك، صُممت النواة الجديدة منذ البداية لدعم بنى معالجات متعددة، بل وتسمح بإنشاء مجموعات غير متجانسة. ولتشغيل النظام بأسرع وقت ممكن، سيتم تنفيذه بدءًا من كود BSD الحالي، ثم إعادة تنفيذه تدريجيًا كبرامج تعتمد على الاتصال بين العمليات (IPC). وهكذا، سيبدأ Mach كنظام متكامل مشابه لأنظمة UNIX الحالية، ويتطور تدريجيًا نحو مفهوم النواة المصغرة. ^{[ 4 ]}

بدأ مشروع Mach في الأساس كجهد لإنتاج لغة برمجة Accent واضحة المعالم، تعتمد على نظام UNIX، وقابلة للنقل بدرجة عالية. وكانت النتيجة قائمة مختصرة من المفاهيم العامة: ^{[ 7 ] [ 8 ]}

• المهمة هي مجموعة من موارد النظام التي تنتج " خيوطًا" لتشغيلها
• الخيط هو وحدة تنفيذ واحدة، موجودة ضمن سياق مهمة ما، وتشارك موارد تلك المهمة .
• المنفذ عبارة عن قائمة انتظار رسائل محمية للاتصال بين المهام؛ وتمتلك المهام حقوق الإرسال والاستقبال (الأذونات) لكل منفذ .
• الرسائل عبارة عن مجموعات من البيانات المكتوبة، ولا يمكن إرسالها إلا إلى المنافذ - وليس تحديدًا إلى المهام أو سلاسل العمليات

استند نظام Mach إلى مفاهيم الاتصال بين العمليات (IPC) الخاصة بنظام Accent، لكنه جعله أقرب إلى نظام UNIX، مما أتاح تشغيل برامج UNIX مع تعديلات طفيفة أو بدون أي تعديلات. ولتحقيق ذلك، قدم Mach مفهوم المنفذ، الذي يمثل كل نقطة نهاية في اتصال ثنائي الاتجاه بين العمليات. كان للمنافذ مفهوم أذونات مشابه لمفهوم الملفات في نظام UNIX، مما سمح بتطبيق نموذج حماية مشابه جدًا لنظام UNIX عليها. بالإضافة إلى ذلك، سمح Mach لأي برنامج بالتعامل مع الصلاحيات التي تُمنح عادةً لنظام التشغيل فقط، وذلك لتمكين برامج مساحة المستخدم من التعامل مع أمور مثل التحكم في الأجهزة.

في نظام التشغيل Mach، كما هو الحال في UNIX، يصبح النظام في الأساس مجموعة من الأدوات المساعدة. وكما هو الحال في UNIX، يحتفظ Mach بمفهوم برنامج التشغيل الخاص بالأجهزة. لذلك، يجب تضمين جميع برامج التشغيل الخاصة بالأجهزة الحالية في النواة المصغرة. أما البنى الأخرى القائمة على طبقة تجريد الأجهزة أو النوى الخارجية، فيمكنها نقل برامج التشغيل خارج النواة المصغرة.

يتمثل الاختلاف الرئيسي مع نظام يونكس في أنه بدلاً من أن تقتصر وظيفة الأدوات المساعدة على معالجة الملفات، يمكنها الآن معالجة أي "مهمة". تم نقل جزء كبير من شيفرة نظام التشغيل من النواة إلى مساحة المستخدم، مما أدى إلى نواة أصغر حجمًا وظهور مصطلح النواة المصغرة . على عكس الأنظمة التقليدية، في نظام ماش، يمكن أن تتكون العملية، أو "المهمة"، من عدد من الخيوط. مع أن هذا شائع في الأنظمة الحديثة، إلا أن ماش كان أول نظام يُعرّف المهام والخيوط بهذه الطريقة. اختُزلت وظيفة النواة من كونها نظام التشغيل الأساسي إلى تشغيل "الأدوات المساعدة" وتوفير إمكانية الوصول إلى المكونات المادية لها.

يُعد وجود المنافذ واستخدام الاتصال بين العمليات (IPC) ربما أهم اختلاف بين نواة Mach والنوى التقليدية. في نظام UNIX، يتألف استدعاء النواة من عملية تُسمى استدعاء النظام أو اعتراض . يستخدم البرنامج مكتبةً لوضع البيانات في موقع معروف في الذاكرة، ثم يُحدث خطأً . عند بدء تشغيل النظام لأول مرة، تُهيأ نواته لتكون "معالجة" جميع الأخطاء؛ وبالتالي، عندما يُحدث برنامج خطأً، تتولى النواة زمام الأمور، وتفحص المعلومات المُمررة إليها، ثم تُنفذ التعليمات.

في نظام Mach، كان يُستخدم نظام الاتصال بين العمليات (IPC) لهذا الغرض. لاستدعاء وظائف النظام، كان البرنامج يطلب من النواة الوصول إلى منفذ، ثم يستخدم نظام الاتصال بين العمليات لإرسال الرسائل إلى ذلك المنفذ. مع أن إرسال رسالة يتطلب استدعاءً للنظام، تمامًا كما يتطلب طلب وظائف النظام على أنظمة أخرى استدعاءً للنظام، فإن إرسال الرسالة في نظام Mach هو تقريبًا كل ما تفعله النواة؛ أما معالجة الطلب الفعلي فتقع على عاتق برنامج آخر.

استفاد دعم الخيوط والتزامن من تمرير الرسائل باستخدام آليات الاتصال بين العمليات، حيث أصبحت المهام تتألف من خيوط برمجية متعددة يمكن لـ Mach تجميدها وإلغاء تجميدها أثناء معالجة الرسائل. يسمح هذا بتوزيع النظام على معالجات متعددة، إما باستخدام الذاكرة المشتركة مباشرةً كما هو الحال في معظم رسائل Mach، أو بإضافة تعليمات برمجية لنسخ الرسالة إلى معالج آخر عند الحاجة. في النواة التقليدية، يصعب تنفيذ ذلك؛ إذ يجب على النظام التأكد من عدم محاولة برامج مختلفة الكتابة إلى نفس منطقة الذاكرة من معالجات مختلفة. مع ذلك، فإن استخدام منافذ Mach يجعل هذا الأمر واضحًا وسهل التنفيذ، لذا أصبحت منافذ Mach عنصرًا أساسيًا في هذا النظام.

واجه نظام الاتصال بين العمليات (IPC) في البداية مشاكل في الأداء، لذا طُوّرت بعض الاستراتيجيات لتحسينه. وكما هو الحال في سلفه، أكسنت، استخدم ماش آلية ذاكرة مشتركة واحدة لنقل الرسائل فعليًا من برنامج إلى آخر. ولأن نسخ الرسائل فعليًا كان سيستغرق وقتًا طويلًا، يعتمد ماش على وحدة إدارة الذاكرة (MMU) في الجهاز لربط البيانات بسرعة بين البرامج. ولا تُنسخ البيانات فعليًا إلا عند الكتابة إليها، وهي عملية تُسمى " النسخ عند الكتابة ".

كما قام نظام التشغيل بفحص صحة الرسائل لتجنب تعطل أي من البرامج العديدة المكونة للنظام بسبب البيانات الخاطئة. وقد صُممت المنافذ عمدًا على غرار مفاهيم نظام ملفات يونكس. وهذا يسمح للمستخدم بالعثور على المنافذ باستخدام مفاهيم التنقل في نظام الملفات، بالإضافة إلى تعيين الحقوق والصلاحيات كما هو الحال في نظام الملفات.

سيكون التطوير في ظل هذا النظام أسهل. لن يقتصر الأمر على وجود الكود قيد العمل ضمن برنامج تقليدي يمكن بناؤه باستخدام الأدوات الحالية، بل يمكن أيضًا تشغيله وتصحيح أخطائه وإيقافه باستخدام الأدوات نفسها. في نظام أحادي النواة، قد يؤدي وجود خطأ في الكود الجديد إلى تعطيل الجهاز بالكامل ويتطلب إعادة تشغيله، بينما في نظام Mach، يكفي إعادة تشغيل البرنامج فقط. إضافةً إلى ذلك، يمكن للمستخدم تخصيص النظام ليشمل أو يستبعد أي ميزات يحتاجها. وبما أن نظام التشغيل عبارة عن مجموعة من البرامج، فيمكن إضافة أو إزالة أجزاء منه ببساطة عن طريق تشغيلها أو إيقافها كما يفعل مع أي برنامج آخر.

وأخيرًا، في ظل نظام التشغيل Mach، صُممت جميع هذه الميزات عمدًا لتكون متوافقة تمامًا مع مختلف المنصات. لنقتبس من أحد النصوص المتعلقة بنظام Mach:

على عكس نظام يونكس، الذي طُوّر دون مراعاة المعالجة المتعددة، يدمج نظام ماش دعم المعالجة المتعددة بشكل كامل. كما يتميز دعمه للمعالجة المتعددة بمرونة فائقة، بدءًا من أنظمة الذاكرة المشتركة وصولًا إلى الأنظمة التي لا تتشارك فيها المعالجات الذاكرة. صُمم ماش ليعمل على أنظمة حاسوبية تتراوح بين معالج واحد وآلاف المعالجات. إضافةً إلى ذلك، يُمكن نقل ماش بسهولة إلى العديد من بنى الحاسوب المتنوعة. يتمثل أحد الأهداف الرئيسية لماش في أن يكون نظامًا موزعًا قادرًا على العمل على أجهزة غير متجانسة. ^{[ 9 ]}

مع ذلك، توجد عدة عيوب. أحدها، وهو عيب بسيط نسبيًا، هو عدم وضوح كيفية العثور على المنافذ. في نظام يونكس، حُلّت هذه المشكلة تدريجيًا، حيث اتفق المبرمجون على عدد من المواقع "المعروفة" في نظام الملفات لأداء وظائف مختلفة. ورغم أن هذا النهج نفسه نجح مع منافذ نظام ماخ، إلا أنه في نظام ماخ، كان يُفترض أن يكون النظام أكثر مرونة، حيث تظهر المنافذ وتختفي باستمرار. وبدون آلية ما للعثور على المنافذ والخدمات التي تمثلها، ستُفقد الكثير من هذه المرونة.

في البداية، تم استضافة Mach كشفرة إضافية مكتوبة مباشرةً في نواة 4.2BSD الحالية، مما أتاح للفريق العمل على النظام قبل اكتماله بفترة طويلة. بدأ العمل بنظام Accent IPC/port الذي كان يعمل بالفعل، ثم انتقل إلى الأجزاء الرئيسية الأخرى من نظام التشغيل: المهام، والخيوط، والذاكرة الافتراضية. مع اكتمال أجزاء من النظام، أُعيدت كتابة أجزاء مختلفة من نظام BSD لاستدعاء Mach، كما أُجري تغيير على 4.3BSD خلال هذه العملية.

بحلول عام ١٩٨٦، اكتمل النظام لدرجة أنه أصبح قادرًا على العمل بشكل مستقل على جهاز DEC VAX . ورغم قلة الفائدة العملية التي حققها، فقد تحقق هدف إنشاء نواة مصغرة. وسرعان ما تبع ذلك إصدارات على جهاز IBM RT PC ومحطات عمل Sun Microsystems 68030 ، مما أثبت قابلية النظام للتنقل. وبحلول عام ١٩٨٧، شملت القائمة أجهزة Encore Multimax و Sequent Balance ، لاختبار قدرة Mach على العمل على أنظمة متعددة المعالجات. وصدر الإصدار الأول للجمهور في ذلك العام، وتبعه الإصدار الثاني في العام التالي.

خلال هذه الفترة، لم يتحقق وعد النواة المصغرة "الحقيقية". تضمنت الإصدارات الأولى من Mach معظم مكونات 4.3BSD في النواة، وهو نظام يُعرف باسم خادم POE، مما أدى إلى نواة أكبر حجمًا من نظام UNIX الذي بُنيت عليه. مع ذلك، كانت الفكرة هي نقل طبقة UNIX من النواة إلى مساحة المستخدم، حيث يسهل العمل عليها، بل واستبدالها بالكامل. لسوء الحظ، أثبت الأداء أنه مشكلة رئيسية، وأُجريت عدة تغييرات معمارية لحل هذه المشكلة. كما عانى الباحثون من مشاكل ترخيص UNIX المعقدة، لذا استمر استخدام هذا الجهد المبكر لتوفير بيئة نظام شبيهة بـ UNIX بدون ترخيص، حتى مع استمرار تطوير Mach.

أُصدر نظام التشغيل Mach 3 في عام 1990، وأثار اهتمامًا واسعًا. قام فريق صغير بتطوير Mach ونقله إلى عدد من المنصات، بما في ذلك أنظمة المعالجات المتعددة المعقدة التي كانت تُسبب مشاكل خطيرة لأنظمة التشغيل القديمة. وقد أثار هذا اهتمامًا كبيرًا في السوق التجارية، حيث كانت العديد من الشركات تُفكر في تغيير منصات الأجهزة. إذا أمكن نقل النظام الحالي ليعمل على Mach، فسيسهل حينها تغيير المنصة الأساسية.

حظي نظام التشغيل Mach باهتمام كبير عندما أعلنت مؤسسة البرمجيات المفتوحة (OSF) أنها ستستضيف الإصدارات المستقبلية من OSF/1 على Mach 2.5، وأنها تدرس أيضًا Mach 3. كما تم اختيار Mach 2.5 لنظام NeXTSTEP وعدد من موردي المعالجات المتعددة التجارية. أدى Mach 3 إلى بذل جهود عديدة لنقل أجزاء من أنظمة تشغيل أخرى إلى النواة المصغرة، بما في ذلك نظام التشغيل Workplace OS من IBM ، والعديد من الجهود التي بذلتها Apple لبناء نسخة متعددة المنصات من نظام التشغيل Mac OS الكلاسيكي . ^{[ 10 ]} وقد أثبت الباحثون دعم تشغيل تطبيقات DOS في بيئة Mach 3.0، استكمالًا لأعمال سابقة لتشغيل نظام التشغيل Mac OS الكلاسيكي و MultiFinder على Mach 2.5. ^{[ 11 ]} درس مشروع بحثي في ​​شركة Digital Equipment Corporation جدوى استضافة OpenVMS على نواة Mach 3، وأنشأ نموذجًا أوليًا باستخدام مجموعة فرعية من ميزات VMS. ^{[ 12 ]}

كان الهدف الأصلي من نظام التشغيل Mach هو استبدال نظام UNIX التقليدي المتكامل، ولذلك احتوى على العديد من الأفكار المشابهة لنظام UNIX. على سبيل المثال، وفّر Mach نظام أذونات وأمان مشابهًا لنظام ملفات UNIX. ولأن النواة كانت تتمتع بصلاحيات مميزة (تعمل في مساحة النواة ) على خوادم وبرامج أنظمة التشغيل الأخرى، كان من الممكن للبرامج المعيبة أو الخبيثة إرسال أوامر إليها تُلحق الضرر بالنظام، ولذلك كانت النواة تتحقق من صحة كل رسالة. بالإضافة إلى ذلك، كان من المقرر أن توجد معظم وظائف نظام التشغيل في برامج مساحة المستخدم، مما يعني ضرورة وجود طريقة ما تُمكّن النواة من منح هذه البرامج صلاحيات إضافية، مثل الوصول المباشر إلى مكونات الجهاز.

استندت بعض ميزات نظام التشغيل Mach الأكثر تخصصًا إلى آلية الاتصال بين العمليات (IPC) نفسها. فعلى سبيل المثال، كان Mach قادرًا على دعم الأجهزة متعددة المعالجات بسهولة. في النواة التقليدية، يتطلب الأمر جهدًا كبيرًا لجعلها قابلة لإعادة الدخول أو المقاطعة ، حيث يمكن للبرامج التي تعمل على معالجات مختلفة استدعاء النواة في الوقت نفسه. أما في Mach، فتُعزل أجزاء نظام التشغيل في خوادم، قادرة على العمل، كأي برنامج آخر، على أي معالج. ورغم أن نواة Mach نظريًا يجب أن تكون قابلة لإعادة الدخول، إلا أن هذا لا يمثل مشكلة عمليًا نظرًا لسرعة استجابتها الفائقة التي تسمح لها بالانتظار وتلبية الطلبات تباعًا. كما تضمن Mach خادمًا قادرًا على إعادة توجيه الرسائل ليس فقط بين البرامج، بل عبر الشبكة أيضًا، وهو مجال شهد تطورًا مكثفًا في أواخر الثمانينيات وأوائل التسعينيات.

لسوء الحظ، تبيّن أن استخدام بروتوكول الاتصال بين العمليات (IPC) في جميع المهام تقريبًا يؤثر سلبًا على الأداء. فقد أظهرت الاختبارات المعيارية على أجهزة عام 1997 أن تطبيقات نظام يونكس أحادية الخادم المبنية على Mach 3.0 كانت أبطأ بنحو 50% من نظام يونكس الأصلي. ^{[ 13 ] [ 14 ]}

كشفت دراسة طبيعة مشاكل الأداء عن عدد من الحقائق المثيرة للاهتمام. إحداها أن الاتصال بين العمليات (IPC) لم يكن هو المشكلة، إذ كان هناك بعض العبء الإضافي المرتبط بتخطيط الذاكرة اللازم لدعمه، لكن هذا لم يُضف سوى وقت ضئيل لإجراء الاستدعاء. أما النسبة المتبقية، 80% من الوقت المُستغرق، فكانت ناتجة عن مهام إضافية كان يُنفذها نظام التشغيل على الرسائل. وكان من أهم هذه المهام التحقق من حقوق المنافذ وصحة الرسائل. في اختبارات الأداء على معالج 486 DX-50، استغرق استدعاء نظام UNIX القياسي 21 ميكروثانية في المتوسط ​​لإكماله، بينما استغرقت العملية المكافئة باستخدام Mach IPC 114 ميكروثانية في المتوسط. 18 ميكروثانية فقط من هذا الوقت كانت متعلقة بالأجهزة، أما الباقي فكان بسبب تشغيل نظام Mach لروتينات مختلفة على الرسالة. ^{[ 15 ]} عند إجراء استدعاء نظام لا يقوم بأي شيء، فإن دورة كاملة ذهابًا وإيابًا في نظام BSD ستستغرق حوالي 40 ميكروثانية، بينما في نظام Mach في مساحة المستخدم ستستغرق أقل من 500 ميكروثانية.

عندما بدأ استخدام Mach بشكل جدي في الإصدارات 2.x، كان الأداء أبطأ من أنظمة التشغيل التقليدية أحادية البنية، ربما بنسبة تصل إلى 25%. ^{[ 1 ]} مع ذلك، لم يُعتبر هذا الأمر مقلقًا بشكل خاص، نظرًا لأن النظام كان يدعم أيضًا المعالجات المتعددة ويسهل نقله. ورأى الكثيرون أن هذه تكلفة متوقعة ومقبولة. عندما حاول Mach 3 نقل معظم نظام التشغيل إلى مساحة المستخدم، ازداد العبء بشكل أكبر: أظهرت المقارنات المعيارية بين Mach و Ultrix على معالج MIPS R3000 انخفاضًا في الأداء يصل إلى 67% في بعض أحمال العمل. ^{[ 16 ]}

على سبيل المثال، يتطلب الحصول على وقت النظام إجراء اتصال بين العمليات (IPC) مع خادم مساحة المستخدم المسؤول عن ساعة النظام . يقوم المستدعي أولاً بالتواصل مع نواة النظام، مما يؤدي إلى تبديل السياق وتعيين الذاكرة. ثم تتحقق النواة من امتلاك المستدعي لصلاحيات الوصول المطلوبة ومن صحة الرسالة. إذا كانت الرسالة صحيحة، يتم إجراء تبديل سياق آخر وتعيين ذاكرة لإتمام الاتصال بخادم مساحة المستخدم. يجب تكرار هذه العملية لإعادة النتائج، ليصل المجموع إلى أربعة عمليات تبديل سياق وتعيين ذاكرة، بالإضافة إلى عمليتي تحقق من الرسالة. يتضاعف هذا العبء بسرعة مع الخدمات الأكثر تعقيدًا، حيث غالبًا ما تمر مسارات التعليمات البرمجية عبر العديد من الخوادم.

لم يكن هذا المصدر الوحيد لمشاكل الأداء. تمحور مصدر آخر حول صعوبة إدارة الذاكرة بكفاءة عند انخفاض الذاكرة الفعلية واضطرار النظام إلى استخدام الترحيل. في أنظمة التشغيل التقليدية المتجانسة، كان لدى مطوري النظام خبرة مباشرة في تحديد أجزاء النواة التي تستدعي أجزاءً أخرى، مما سمح لهم بضبط نظام الترحيل بدقة لتجنب ترحيل التعليمات البرمجية التي ستُستخدم قريبًا. في نظام Mach، لم يكن هذا ممكنًا لأن النواة لم تكن على دراية حقيقية بمكونات نظام التشغيل. لذا، اضطروا إلى استخدام حل واحد شامل، مما زاد من مشاكل الأداء. حاول Mach 3 معالجة هذه المشكلة بتوفير نظام ترحيل بسيط، معتمدًا على أنظمة الترحيل في مساحة المستخدم لتحسين التخصيص. لكن تبين أن هذا الحل لم يكن فعالًا. عمليًا، تلاشت أي فوائد محتملة بسبب تكلفة الاتصال بين العمليات اللازمة لاستدعائه.

تضمنت مشاكل الأداء الأخرى دعم Mach لأنظمة المعالجات المتعددة . فمن منتصف الثمانينيات إلى أوائل التسعينيات، شهدت وحدات المعالجة المركزية التجارية نموًا في الأداء بمعدل 60% سنويًا، بينما لم تتجاوز سرعة الوصول إلى الذاكرة 7% سنويًا. هذا يعني أن تكلفة الوصول إلى الذاكرة ارتفعت بشكل كبير خلال هذه الفترة، ولأن Mach كان يعتمد على ربط الذاكرة بين البرامج، فإن أي "فقدان للذاكرة المؤقتة" كان يُبطئ استدعاءات IPC.

يُعدّ عبء الاتصال بين العمليات مشكلة رئيسية لأنظمة Mach 3. لا يزال مفهوم نظام التشغيل متعدد الخوادم واعدًا، مع أنه لا يزال بحاجة إلى مزيد من البحث. يجب على المطورين توخي الحذر لعزل التعليمات البرمجية في وحدات لا تتصل بين الخوادم. على سبيل المثال، يُوضع الجزء الأكبر من تعليمات الشبكة في خادم واحد، مما يقلل من عبء الاتصال بين العمليات في مهام الشبكة الاعتيادية.

بدلاً من ذلك، التزم معظم المطورين بمفهوم POE الأصلي، الذي يعتمد على خادم واحد كبير يوفر وظائف نظام التشغيل. ^{[ 17 ]} ولتسهيل عملية التطوير، سمحوا بتشغيل خادم نظام التشغيل إما في مساحة المستخدم أو في مساحة النواة. مكّنهم هذا من التطوير في مساحة المستخدم والاستفادة من جميع مزايا فكرة Mach الأصلية، ثم نقل الخادم الذي تم تصحيحه إلى مساحة النواة لتحسين الأداء. ومنذ ذلك الحين، تم بناء العديد من أنظمة التشغيل باستخدام هذه الطريقة، المعروفة باسم التجميع ، ومنها Lites و MkLinux و OSF/1 وNeXTSTEP/OPENSTEP/macOS. وقد جعلت نواة Chorus المصغّرة هذه الميزة جزءًا من النظام الأساسي، مما يسمح بتشغيل الخوادم في مساحة النواة باستخدام آليات مدمجة.

حاول نظام التشغيل Mach 4 معالجة هذه المشاكل من خلال مجموعة من التحسينات الجذرية. على وجه الخصوص، تبيّن أن شفرة البرنامج عادةً ما تكون غير قابلة للكتابة، لذا كانت احتمالية حدوث أخطاء بسبب النسخ عند الكتابة نادرة. وبالتالي، كان من المنطقي عدم ربط الذاكرة بين البرامج للتواصل بين العمليات، بل نقل شفرة البرنامج المستخدمة إلى المساحة المحلية للبرنامج. أدى هذا إلى ظهور مفهوم "المكوك"، وبدا أن الأداء قد تحسّن، لكن المطورين واصلوا العمل على النظام وهو في حالة شبه قابلة للاستخدام. كما قدّم نظام Mach 4 أيضًا أدوات التجميع المدمجة، مما جعلها جزءًا من نواة النظام.

بحلول منتصف التسعينيات، كان العمل على أنظمة النواة المصغرة راكدًا إلى حد كبير، على الرغم من أن السوق كان يعتقد عمومًا أن جميع أنظمة التشغيل الحديثة ستكون قائمة على النواة المصغرة بحلول التسعينيات. يُعد نظام macOS من Apple ونظام iOS الشقيق له من أبرز الاستخدامات المتبقية واسعة الانتشار لنواة Mach، حيث يعملان على نواة Mach هجينة معدلة بشكل كبير من مؤسسة البرمجيات المفتوحة (OSFMK 7.3) تُسمى " XNU " ^{[ 18 ]،} والتي تُستخدم أيضًا في OSF/1. ^{[ 10 ]} في XNU، تُنفذ أنظمة الملفات، ومكدسات الشبكات، ووظائف إدارة العمليات والذاكرة في النواة؛ ويتم استدعاء نظام الملفات والشبكات وبعض وظائف إدارة العمليات والذاكرة من وضع المستخدم عبر استدعاءات النظام العادية بدلًا من تمرير الرسائل؛ ^{[ 19 ] [ 20 ]} تُستخدم رسائل Mach في XNU للتواصل بين عمليات وضع المستخدم، ولبعض الطلبات من كود وضع المستخدم إلى النواة ومن النواة إلى خوادم وضع المستخدم.

أظهر تحليل إضافي أن مشكلة أداء الاتصال بين العمليات لم تكن واضحة كما بدت. تجدر الإشارة إلى أن تنفيذ جانب واحد من استدعاء النظام استغرق 20 ميكروثانية في نظام BSD ^{[ 3 ]} و114 ميكروثانية في نظام Mach الذي يعمل على نفس النظام. ^{[ 2 ]} من بين الـ 114 ميكروثانية، كان 11 ميكروثانية منها ناتجًا عن تبديل السياق، وهو ما يتطابق مع نظام BSD. ^{[ 14 ]} واستخدمت وحدة إدارة الذاكرة (MMU) 18 ميكروثانية إضافية لربط الرسالة بين مساحة المستخدم ومساحة النواة. ^{[ 3 ]} وبذلك يصل المجموع إلى 29 ميكروثانية فقط، وهي مدة أطول من استدعاء النظام التقليدي، ولكن ليس بفارق كبير.

أما الجزء الأكبر من المشكلة، فيعود إلى قيام نواة النظام بمهام مثل التحقق من صلاحيات الوصول إلى المنافذ في الرسالة. ^{[ 6 ]} ورغم أن هذا قد يبدو مصدر قلق أمني بالغ، إلا أنه في الواقع لا يُجدي نفعًا إلا في أنظمة شبيهة بنظام يونكس. فعلى سبيل المثال، قد لا يحتاج نظام تشغيل أحادي المستخدم، يُستخدم لتشغيل هاتف محمول أو روبوت، إلى أي من هذه الميزات، وهذا تحديدًا هو نوع النظام الذي يكون فيه نظام التشغيل "الاختياري" الخاص بـ Mach ذا قيمة كبيرة. وبالمثل، تسبب Mach في مشاكل عند نقل الذاكرة بواسطة نظام التشغيل، وهي مهمة أخرى لا تُجدي نفعًا إلا إذا كان النظام يحتوي على أكثر من مساحة عناوين. أما نظاما DOS و Mac OS في بداياتهما، فيحتويان على مساحة عناوين كبيرة واحدة مشتركة بين جميع البرامج، لذا لم يُوفر هذا التعيين أي فوائد في ظل هذه الأنظمة.

أدت هذه الاستنتاجات إلى ظهور سلسلة من النوى المصغرة من الجيل الثاني، والتي قللت من تعقيد النظام بشكل أكبر، ووضعت جميع الوظائف تقريبًا في مساحة المستخدم. على سبيل المثال، تتضمن نواة L4 (الإصدار 2) سبعة استدعاءات نظام فقط، وتستخدم 12 كيلوبايت من الذاكرة، ^{[ 3 ]} بينما تتضمن Mach 3 حوالي 140 دالة، وتستخدم حوالي 330 كيلوبايت من الذاكرة. ^{[ 3 ]} تستغرق استدعاءات الاتصال بين العمليات (IPC) في نواة L4 على معالج 486DX-50 خمس ميكروثانية فقط، ^{[ 20 ]} أي أسرع من استدعاء نظام UNIX على نفس النظام، وأسرع بأكثر من 20 مرة من Mach. بالطبع، هذا يتجاهل حقيقة أن L4 لا تتعامل مع الأذونات أو الأمان؛ ولكن بترك هذه المهمة لبرامج مساحة المستخدم، يمكنها اختيار مقدار الحمل الزائد الذي تحتاجه.

تُحدّ من المكاسب المحتملة في أداء طبقة التخزين L4 حقيقة أن تطبيقات مساحة المستخدم ستضطر غالبًا إلى توفير العديد من الوظائف التي كانت تدعمها النواة سابقًا. ولاختبار الأداء الشامل، قورن نظام MkLinux في وضع التشغيل المشترك مع منفذ L4 يعمل في مساحة المستخدم. أضافت طبقة التخزين L4 ما يقارب 5% إلى 10% من الحمل الزائد، ^{[ 14 ]} مقارنةً بنسبة 29% التي أضافها نظام Mach. ^{[ 14 ]}