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

نافذة "حول هذا الكمبيوتر" في نظام التشغيل Mac OS 9.1 تعرض استهلاك الذاكرة لكل تطبيق مفتوح وبرنامج النظام نفسه

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

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

التجزئة

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

كان نظام إدارة الذاكرة يعاني من نقاط ضعف؛ إذ لم تكن كومة النظام محمية من التطبيقات المعيبة، كما كان ممكنًا لو أن بنية النظام تدعم حماية الذاكرة ، وكان هذا سببًا متكررًا لمشاكل النظام وتعطله. [ 4 ] إضافةً إلى ذلك، أدى استخدام المؤشرات إلى ظهور مصدر لأخطاء البرمجة، حيث لم يكن بالإمكان ضمان بقاء المؤشرات إلى البيانات داخل هذه الكتل القابلة للنقل صالحةً عبر الاستدعاءات التي قد تتسبب في نقل الذاكرة. كانت هذه مشكلة حقيقية لجميع واجهات برمجة التطبيقات ( APIs) تقريبًا . ونظرًا لشفافية هياكل البيانات المملوكة للنظام في ذلك الوقت، لم يكن بإمكان واجهات برمجة التطبيقات فعل الكثير لحل هذه المشكلة. وبالتالي، كان على المبرمج تجنب إنشاء مثل هذه المؤشرات، أو على الأقل إدارتها بعناية فائقة عن طريق إلغاء مرجعية جميع المؤشرات بعد كل استدعاء لواجهة برمجة التطبيقات. ولأن العديد من المبرمجين لم يكونوا على دراية بهذا الأسلوب، فقد عانت برامج ماك المبكرة بشكل متكرر من أخطاء ناتجة عنه. [ 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 ، الذي مكّن أجهزة ماك المزودة  بذاكرة 512 كيلوبايت أو أكثر من تشغيل تطبيقات متعددة في آن واحد. [ 7 ] كانت هذه خطوة ضرورية للمستخدمين الذين وجدوا أسلوب تشغيل تطبيق واحد في كل مرة محدودًا للغاية. ولأن شركة آبل كانت ملتزمة بنموذج إدارة الذاكرة الخاص بها، بالإضافة إلى التوافق مع التطبيقات الحالية، فقد اضطرت إلى تبني آلية يتم فيها تخصيص مساحة تخزين (heap) لكل تطبيق من ذاكرة الوصول العشوائي (RAM) المتاحة. يتم تحديد مقدار ذاكرة الوصول العشوائي المخصصة لكل مساحة تخزين من خلال قيمة مُبرمجة في بيانات تعريف كل تطبيق، يحددها المبرمج. في بعض الأحيان، لم تكن هذه القيمة كافية لأنواع معينة من العمل، لذلك كان لا بد من إتاحة إعداد القيمة للمستخدم لتمكينه من تعديل حجم مساحة التخزين بما يتناسب مع متطلباته. على الرغم من شيوع هذه الطريقة بين " المستخدمين المتقدمين "، إلا أن الكشف عن تفاصيل التنفيذ التقنية كان مخالفًا لفلسفة مستخدمي ماك. إلى جانب تعريض المستخدمين لتفاصيل تقنية معقدة، كان هذا الأسلوب غير فعال، إذ كان التطبيق يستحوذ على كامل ذاكرة الوصول العشوائي المخصصة له، حتى لو ترك معظمها غير مستخدم لاحقًا. وقد يعاني تطبيق آخر من نقص في الذاكرة، لكنه لن يتمكن من استخدام الذاكرة الحرة "المملوكة" لتطبيق آخر. [ 3 ]

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

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

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

نسخة نظيفة 32 بت

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

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

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

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

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

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

توجيه الكائن

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

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

مراجع

  1. هيرتزفيلد، آندي (سبتمبر 1983)، ماكنتوش الأصلي: لسنا قراصنة!، تم الاطلاع عليه في 10 مايو 2010
  2. هيرتزفيلد، آندي (يناير 1982)، ماكنتوش الأصلي: المجرية ، مؤرشف من الأصل في 19 يونيو 2010 ، تم استرجاعه في 10 مايو 2010
  3. 1 2 3 memorymanagement.org (15 ديسمبر 2000)، إدارة الذاكرة في نظام التشغيل ماك ، مؤرشف من الأصل في 16 مايو 2010 ، تم استرجاعه في 10 مايو 2010
  4. 1 2 هيرتزفيلد، آندي ، ماكنتوش الأصلي: ميا كولبا ، تم الاطلاع عليه في 10 مايو 2010
  5. شركة أبل للكمبيوتر (1 أكتوبر 1985)، الملاحظة الفنية OV09: تصحيح الأخطاء باستخدام PurgeMem و CompactMem ، تم الاطلاع عليها في 10 مايو 2010
  6. 1 2 3 مرجع إدارة الذاكرة القديمة ، شركة أبل ، 27 يونيو 2007 ، تم الاطلاع عليه في 10 مايو 2010
  7. هيرتزفيلد، آندي (أكتوبر 1984)، ماكنتوش الأصلي: المبدل ، تم الاطلاع عليه في 10 مايو 2010
  8. "دليل ترقية النظام 7.1" (ملف PDF) . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 4 مارس 2016. تم الاطلاع عليه بتاريخ 26 مايو 2015 .
  9. الانتقال من عنونة 24 بت إلى عنونة 32 بت - واجهة المستخدم الرسومية لنظام ماك
  10. "خرائط الذاكرة" . Osdata.com. 28 مارس 2001. تم الاطلاع عليه في 11 مايو 2010 .
  11. أرشيف دايستار، الأسئلة الشائعة حول الوضع 32 - LowEndMac
  12. MODE32 الإصدار 7.5 - ملاحظات وتعليمات هامة حول الإصدار
  13. شركة أبل للكمبيوتر (1 يناير 1991)، الملاحظة الفنية ME13: توافق مدير الذاكرة ، تم الاطلاع عليها في 10 مايو 2010
  14. توصيات تخصيص الذاكرة على نظام التشغيل OS X ، شركة أبل ، 12 يوليو 2005 ، تم الاطلاع عليها في 22 سبتمبر 2009
  • ماكنتوش: حجم ذاكرة القراءة فقط (ROM) لمختلف الطرازات ، شركة أبل ، 23 أغسطس 2000، مؤرشف من الأصل في 15 أكتوبر 2009 ، تم استرجاعه في 22 سبتمبر 2009