إدارة الذاكرة الكلاسيكية لنظام التشغيل Mac OS

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2020) (Learn how and when to remove this message)

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

كانت المشكلة الأصلية التي واجهها مهندسو جهاز ماكنتوش هي كيفية تحقيق الاستخدام الأمثل لذاكرة الوصول العشوائي (RAM) التي تبلغ سعتها 128 كيلوبايت والتي تم تجهيز الجهاز بها، على أجهزة كمبيوتر تعتمد على معالج موتورولا 68000 والتي لا تدعم الذاكرة الافتراضية . ^[1] نظرًا لأنه في ذلك الوقت كان الجهاز قادرًا فقط على تشغيل برنامج تطبيق واحد في كل مرة، ولم يكن هناك تخزين ثانوي ثابت ، فقد نفذ المهندسون مخططًا بسيطًا يعمل بشكل جيد مع تلك القيود المعينة. لم يتناسب اختيار التصميم هذا جيدًا مع تطوير الجهاز، مما خلق صعوبات مختلفة لكل من المبرمجين والمستخدمين.

يبدو أن الاهتمام الأساسي للمهندسين الأصليين كان بالتجزئة - أي التخصيص المتكرر وإلغاء تخصيص الذاكرة من خلال المؤشرات مما يؤدي إلى العديد من المناطق المعزولة الصغيرة من الذاكرة والتي لا يمكن استخدامها لأنها صغيرة جدًا، على الرغم من أن إجمالي الذاكرة الحرة قد تكون كافية لتلبية طلب معين للذاكرة. لحل هذه المشكلة، استخدم مهندسو Apple مفهوم المقبض القابل للنقل ، وهو مرجع للذاكرة يسمح بنقل البيانات الفعلية المشار إليها دون إبطال المقبض. كان مخطط Apple بسيطًا - كان المقبض ببساطة مؤشرًا إلى جدول (غير قابل للنقل) من المؤشرات الإضافية، والتي تشير بدورها إلى البيانات. ^[2] إذا تطلب طلب الذاكرة ضغط الذاكرة، يتم ذلك ويتم تحديث الجدول، المسمى كتلة المؤشر الرئيسية. نفذت الآلة نفسها منطقتين في الذاكرة المتاحة لهذا المخطط - كومة النظام (تستخدم لنظام التشغيل)، وكومة التطبيق. ^[3] طالما تم تشغيل تطبيق واحد فقط في كل مرة، كان النظام يعمل بشكل جيد. نظرًا لأن كومة التطبيق بالكامل تم حلها عند خروج التطبيق، فقد تم تقليل التجزئة.

كان نظام إدارة الذاكرة يعاني من نقاط ضعف؛ لم تكن كومة النظام محمية من التطبيقات الخاطئة، كما كان من الممكن أن يكون الأمر إذا كانت بنية النظام تدعم حماية الذاكرة ، وكان هذا غالبًا سببًا لمشاكل النظام وتعطله. ^[4] بالإضافة إلى ذلك، فتح النهج القائم على المقبض أيضًا مصدرًا لأخطاء البرمجة، حيث لا يمكن ضمان بقاء المؤشرات إلى البيانات داخل مثل هذه الكتل القابلة للنقل صالحة عبر المكالمات التي قد تتسبب في نقل الذاكرة. كانت هذه مشكلة حقيقية لكل واجهة برمجة تطبيقات للنظام موجودة تقريبًا. نظرًا لشفافية هياكل البيانات المملوكة للنظام في ذلك الوقت، لم تستطع واجهات برمجة التطبيقات فعل الكثير لحل هذه المشكلة. وبالتالي كان العبء يقع على عاتق المبرمج ألا ينشئ مثل هذه المؤشرات، أو على الأقل إدارتها بعناية شديدة عن طريق إلغاء الرجوع إلى جميع المقابض بعد كل مكالمة واجهة برمجة تطبيقات من هذا القبيل. نظرًا لأن العديد من المبرمجين لم يكونوا على دراية بهذا النهج بشكل عام، فقد عانت برامج Mac المبكرة بشكل متكرر من الأخطاء الناشئة عن هذا. ^[5]

يستخدم Palm OS وWindows 16 بت مخططًا مشابهًا لإدارة الذاكرة، لكن إصدارات Palm وWindows تجعل خطأ المبرمج أكثر صعوبة. على سبيل المثال، في نظام التشغيل Mac OS، لتحويل مقبض إلى مؤشر، يقوم البرنامج فقط بإلغاء مرجع المقبض مباشرةً، ولكن إذا لم يكن المقبض مقفلاً، فقد يصبح المؤشر غير صالح بسرعة. لا تتم موازنة المكالمات لقفل وفتح المقابض؛ HLockيتم التراجع عن عشر مكالمات إلى بواسطة مكالمة واحدة إلى HUnlock. ^[6] في نظام التشغيل Palm OS وWindows، تكون المقابض من النوع غير الشفاف ويجب إلغاء مرجعها بـ MemHandleLockعلى نظام التشغيل Palm OS أو Global/LocalLockعلى نظام التشغيل Windows. عندما ينتهي تطبيق Palm أو Windows من مقبض، فإنه يستدعي MemHandleUnlockأو Global/LocalUnlock. يحتفظ نظام التشغيل Palm OS وWindows بعدد قفل للكتل؛ بعد ثلاث مكالمات إلى MemHandleLock، لن يتم فتح قفل الكتلة إلا بعد ثلاث مكالمات إلى MemHandleUnlock.

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

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

ازداد الوضع سوءًا مع ظهور Switcher ، وهو وسيلة لجهاز Mac بسعة 512 كيلوبايت أو أكثر من الذاكرة لتشغيل تطبيقات متعددة في وقت واحد. ^[7] كانت هذه خطوة ضرورية إلى الأمام للمستخدمين، الذين وجدوا أن نهج تطبيق واحد في كل مرة محدود للغاية. نظرًا لأن Apple كانت ملتزمة الآن بنموذج إدارة الذاكرة الخاص بها، بالإضافة إلى التوافق مع التطبيقات الحالية، فقد اضطرت إلى تبني مخطط حيث تم تخصيص كومة خاصة به لكل تطبيق من ذاكرة الوصول العشوائي المتاحة. تم تعيين مقدار ذاكرة الوصول العشوائي الفعلية المخصصة لكل كومة من خلال قيمة مشفرة في البيانات الوصفية لكل تطبيق، والتي حددها المبرمج. في بعض الأحيان لم تكن هذه القيمة كافية لأنواع معينة من العمل، لذلك كان لا بد من الكشف عن إعداد القيمة للمستخدم للسماح له بتعديل حجم الكومة لتناسب متطلباته الخاصة. على الرغم من شعبيته بين " مستخدمي الطاقة "، إلا أن هذا الكشف عن تفاصيل التنفيذ الفني كان يتعارض مع فلسفة مستخدمي Mac. بصرف النظر عن تعريض المستخدمين لتفاصيل فنية غامضة، فقد كان هذا غير فعال، حيث كان من الممكن أن يتم إجبار أحد التطبيقات على الاستيلاء على كل ذاكرة الوصول العشوائي المخصصة له، حتى لو ترك معظمها غير مستخدم لاحقًا. قد يكون تطبيق آخر محرومًا من الذاكرة، لكنه لن يتمكن من الاستفادة من الذاكرة الخالية "المملوكة" لتطبيق آخر. ^[3]

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

تطور برنامج Switcher إلى MultiFinder في نظام التشغيل 4.2، والذي أصبح مدير العمليات في نظام التشغيل 7 ، وبحلول ذلك الوقت كان المخطط قد ترسخ منذ فترة طويلة. قامت شركة Apple ببعض المحاولات للتغلب على القيود الواضحة - كانت الذاكرة المؤقتة واحدة منها، حيث يمكن للتطبيق "استعارة" ذاكرة الوصول العشوائي المجانية الموجودة خارج كومتها لفترات قصيرة، لكن هذا لم يكن شائعًا لدى المبرمجين لذلك فشل إلى حد كبير في حل المشكلات. أضافت الوظيفة الإضافية System 7 Tune-up من Apple حجم ذاكرة "أدنى" وحجم "مفضل" - إذا لم يكن مقدار الذاكرة المفضل متاحًا، فيمكن تشغيل البرنامج في الحد الأدنى من المساحة، ربما مع وظائف مخفضة. تم دمج هذا في نظام التشغيل القياسي بدءًا من نظام التشغيل 7.1، لكنه لم يعالج المشكلة الجذرية. ^[8]

تم توفير مخططات الذاكرة الافتراضية ، التي جعلت المزيد من الذاكرة متاحة عن طريق ترحيل أجزاء غير مستخدمة من الذاكرة إلى القرص، بواسطة أدوات مساعدة خارجية مثل Connectix Virtual، ثم بواسطة Apple في نظام التشغيل System 7. أدى هذا إلى زيادة سعة ذاكرة Macintosh على حساب الأداء، لكنه لم يضف ذاكرة محمية أو يمنع ضغط كومة مدير الذاكرة الذي قد يبطل بعض المؤشرات.

في الأصل كان لدى Macintosh 128 كيلوبايت من ذاكرة الوصول العشوائي، مع حد حقيقي يبلغ 4 ميجا بايت، على الرغم من اللحام. تم الوصول إلى هذا الحد لأول مرة مع Macintosh Plus وذاكرته القابلة للترقية من قبل المستخدم. تستخدم أجهزة كمبيوتر Macintosh القليلة الأولى وحدة المعالجة المركزية 68000 ، وهي معالج 32 بت، يحتوي على 24 سطرًا فقط من العناوين المادية. تسمح الخطوط الـ 24 للمعالج بمعالجة ما يصل إلى 16 ميجا بايت من الذاكرة (2 ²⁴ بايت)، والتي كانت تعتبر كمية كافية في ذلك الوقت. كان حد ذاكرة الوصول العشوائي في تصميم Macintosh 4 ميجا بايت من ذاكرة الوصول العشوائي و4 ميجا بايت من ذاكرة القراءة فقط مع تقسيم عناوين 8 ميجا بايت المتبقية بين شرائح SCC وIWM وVIA ، بسبب بنية خريطة الذاكرة. ^{[9] [10]} تم إصلاح هذه المشكلة عن طريق تغيير خريطة الذاكرة باستخدام Macintosh II ، مما يسمح بما يصل إلى 8 ميجا بايت من ذاكرة الوصول العشوائي، عن طريق تقليص عناوين ROM وI/O إلى 1 ميجا بايت لكل منهما وتخصيص عناوين 6 ميجا بايت المتبقية لفتحات NuBus . سمحت منتجات Connectix MAXIMA وRAM Doubler وVirtual بالوصول إلى عناوين 6 ميجا بايت المخصصة لبطاقات NuBus وإعادة تخصيصها بإجمالي 14 ميجا بايت، ناقص 1 ميجا بايت لكل فتحة مشغولة. ^{[11] [12]}

نظرًا لأن الذاكرة كانت موردًا نادرًا، فقد قرر مؤلفو نظام التشغيل Mac OS الكلاسيكي الاستفادة من البايت غير المستخدم في كل عنوان. وضع مدير الذاكرة الأصلي (حتى ظهور نظام التشغيل System 7) علامات في أعلى 8 بتات لكل مؤشر ومقبض 32 بت. احتوى كل عنوان على علامات مثل "مقفل" أو "قابل للتطهير" أو "مورد"، والتي تم تخزينها في جدول المؤشرات الرئيسي. عند استخدامها كعنوان فعلي، تم إخفاء هذه العلامات وتجاهلها بواسطة وحدة المعالجة المركزية. ^[4]

على الرغم من أن هذا التصميم يمثل استخدامًا جيدًا لمساحة ذاكرة وصول عشوائي محدودة للغاية، إلا أنه تسبب في حدوث مشكلات عندما قدمت شركة Apple جهاز Macintosh II، الذي استخدم وحدة المعالجة المركزية Motorola 68020 ذات 32 بت . كان جهاز 68020 يحتوي على 32 سطرًا للعناوين المادية يمكنها معالجة ما يصل إلى 4 جيجابايت من الذاكرة. أصبحت العلامات التي يخزنها مدير الذاكرة في البايت الأعلى لكل مؤشر ومقبض مهمة الآن، ويمكن أن تؤدي إلى أخطاء في المعالجة.

في أجهزة Macintosh IIci والإصدارات اللاحقة، HLock()تمت إعادة كتابة واجهات برمجة التطبيقات الأخرى لتنفيذ قفل المقبض بطريقة أخرى غير تمييز البتات العالية من المقابض. لكن العديد من مبرمجي تطبيقات Macintosh والكثير من أكواد برامج نظام Macintosh نفسها تمكنوا من الوصول إلى العلامات بشكل مباشر بدلاً من استخدام واجهات برمجة التطبيقات، مثل HLock()، والتي تم توفيرها للتلاعب بها. من خلال القيام بذلك، جعلوا تطبيقاتهم غير متوافقة مع عنونة 32 بت الحقيقية، وأصبح هذا معروفًا بأنه "غير نظيف 32 بت".

من أجل إيقاف الأعطال المستمرة للنظام الناتجة عن هذه المشكلة، فإن نظام التشغيل 6 والإصدارات الأقدم التي تعمل على معالج 68020 أو 68030 ستجبر الجهاز على الدخول في وضع 24 بت، ولن يتعرف إلا على أول 8 ميجا بايت من ذاكرة الوصول العشوائي (RAM) ويتعامل معها، وهو عيب واضح في الأجهزة التي تم توصيل أجهزتها لقبول ما يصل إلى 128 ميجا بايت من ذاكرة الوصول العشوائي (RAM) - والتي أعلنت كتيبات منتجاتها عن هذه القدرة. مع نظام التشغيل 7، تم أخيرًا جعل برنامج نظام Mac نظيفًا من 32 بت، ولكن لا تزال هناك مشكلة أقراص ROM المتسخة. كانت المشكلة أن قرار استخدام عنونة 24 بت أو 32 بت يجب أن يتم في وقت مبكر جدًا من عملية التمهيد، عندما تقوم روتينات ROM بتهيئة Memory Manager لإعداد بيئة Mac أساسية حيث يتم تحميل أقراص ROM NuBus وبرامج تشغيل القرص وتنفيذها. لم يكن لدى أقراص ROM الأقدم أي دعم لـ Memory Manager 32 بت وبالتالي لم يكن من الممكن التمهيد في وضع 32 بت. من المثير للدهشة أن الحل الأول لهذا الخلل تم نشره بواسطة شركة Connectix للبرامج ، والتي أعادت امتدادها لنظام 6، OPTIMA، تهيئة مدير الذاكرة وكررت الأجزاء المبكرة من عملية تمهيد Mac، مما يسمح للنظام بالتمهيد في وضع 32 بت وتمكين استخدام كل ذاكرة الوصول العشوائي في الجهاز. تطور OPTIMA لاحقًا إلى المنتج الأكثر شيوعًا لعام 1991، MODE32 ، لنظام 7. قامت Apple بترخيص البرنامج من Connectix في وقت لاحق من عام 1991 ووزعته مجانًا. كان لدى أجهزة كمبيوتر Macintosh IIci وأجهزة كمبيوتر Macintosh التي تعتمد على Motorola لاحقًا أقراص ROM نظيفة 32 بت.

لقد مر وقت طويل قبل تحديث التطبيقات لإزالة جميع التبعيات ذات الـ 24 بت، وقد وفر نظام 7 طريقة للتبديل مرة أخرى إلى وضع 24 بت إذا تم العثور على عدم توافق في التطبيقات. ^[3] بحلول وقت الانتقال إلى PowerPC وSystem 7.1.2، كان نظافة 32 بت إلزامية لإنشاء تطبيقات أصلية وحتى في وقت لاحق، لم تتمكن أجهزة Mac المستندة إلى Motorola 68040 من دعم وضع 24 بت. ^{[6] [13]}

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

في حين ظل نموذج ذاكرة Mac OS، مع كل مشاكله المتأصلة، على هذا النحو حتى Mac OS 9 ، بسبب قيود توافق التطبيقات الشديدة، فإن التوافر المتزايد لذاكرة الوصول العشوائي الرخيصة يعني أنه في العموم يمكن لمعظم المستخدمين الترقية إلى طريقهم للخروج من الزاوية. لم يتم استخدام الذاكرة بكفاءة، لكنها كانت وفيرة بما يكفي بحيث لم تصبح المشكلة حرجة أبدًا. وهذا أمر مثير للسخرية نظرًا لأن الغرض من التصميم الأصلي كان تعظيم استخدام كميات محدودة للغاية من الذاكرة. تخلص Mac OS X أخيرًا من المخطط بالكامل، ونفذ مخطط ذاكرة افتراضية مقسمة حديثًا . لا تزال مجموعة فرعية من واجهات برمجة تطبيقات نموذج الذاكرة الأقدم موجودة للتوافق كجزء من Carbon ، لكنها ترتبط بمدير الذاكرة الحديث ( mallocتنفيذ آمن للخيوط) في الأسفل. ^[6] توصي Apple بأن يستخدم كود Mac OS Xmalloc و free"حصريًا تقريبًا". ^[14]

• Macintosh: حجم ذاكرة القراءة فقط للطرازات المختلفة، Apple Inc ، 23 أغسطس 2000 ، تم الاسترجاع في 22 سبتمبر 2009