クラシックMac OSのメモリ管理

歴史的に、クラシック Mac OS は、現代のシステムでは好まれなくなった形式のメモリ管理を使用していました。このアプローチに対する批判は、 Mac OS Xへの変更によって対処された重要な領域の 1 つでした。

Macintoshのエンジニアにとっての当初の問題は、仮想メモリをサポートしていないモトローラ68000ベースのコンピュータハードウェア上で、マシンに搭載された128KBのRAMをいかに最適に活用するかということでした。^[1]当時のマシンは一度に1つのアプリケーションプログラムしか実行できず、固定の二次記憶装置もなかったため、エンジニアはこれらの特定の制約にうまく適合する単純な方式を実装しました。この設計上の選択はマシンの開発に合わせて拡張できず、プログラマとユーザーの両方にさまざまな困難をもたらしました。

当初のエンジニアの主な懸念は断片化だったようです。つまり、ポインターを介してメモリの割り当てと解放を繰り返すと、空きメモリの合計が特定のメモリ要求を満たすのに十分であるにもかかわらず、小さすぎるために使用できない多くの小さな孤立したメモリ領域が発生します。これを解決するために、Appleのエンジニアは、再配置可能なハンドルの概念を使用しました。これは、参照される実際のデータをハンドルを無効にすることなく移動できるメモリへの参照です。Apple のスキームはとてもシンプルで、ハンドルは、データを指すポインターの (再配置不可能な) テーブルへのポインターにすぎませんでした。^[2]メモリ要求がメモリの圧縮を必要とする場合、これが行われ、マスター ポインター ブロックと呼ばれるテーブルが更新されました。マシン自体は、このスキームに使用できる 2 つのメモリ領域を実装しました。システム ヒープ (OS 用) とアプリケーション ヒープです。^[3]一度に 1 つのアプリケーションだけが実行されている限り、システムは正常に動作しました。アプリケーションが終了するとアプリケーション ヒープ全体が解消されるため、断片化は最小限に抑えられました。

メモリ管理システムには弱点があった。システム ヒープは、システム アーキテクチャがメモリ保護をサポートしていれば可能だったはずの誤ったアプリケーションから保護されておらず、これがシステムの問題やクラッシュの原因になることが多かった。^[4]さらに、ハンドル ベースのアプローチはプログラミング エラーの原因にもなり、そのような再配置可能なブロック内のデータへのポインターは、メモリの移動を引き起こす可能性のある呼び出し間で有効のままであることを保証できなかった。これは、存在するほぼすべてのシステムAPIにとって現実的な問題だった。当時のシステム所有のデータ構造は透過的であったため、API ではこの問題を解決できなかった。したがって、そのようなポインターを作成しないか、少なくともそのような API 呼び出しのたびにすべてのハンドルを逆参照して非常に注意深く管理する責任はプログラマーに課せられた。多くのプログラマーがこのアプローチに一般的に精通していなかったため、初期の Mac プログラムは、これに起因する障害に頻繁に悩まされた。^[5]

Palm OSと 16 ビット Windows はメモリ管理に同様のスキームを使用していますが、Palm および Windows バージョンではプログラマーのエラーがより起こりにくくなっています。たとえば、Mac OS では、ハンドルをポインターに変換するには、プログラムはハンドルを直接逆参照するだけですが、ハンドルがロックされていない場合、ポインターはすぐに無効になる可能性があります。ハンドルのロックとロック解除の呼び出しはバランスが取れておらず、 の 10 回の呼び出しは、HLockの 1 回の呼び出しで元に戻されますHUnlock。^[6]MemHandleLock Palm OS と Windows では、ハンドルは不透明な型であり、 Palm OS では 、 Windows ではを使用して逆参照する必要がありますGlobal/LocalLock。Palm または Windows アプリケーションは、ハンドルの使用を終了すると、MemHandleUnlockまたは を呼び出しますGlobal/LocalUnlock。Palm OS と Windows はブロックのロック カウントを保持します。 を 3 回呼び出した後はMemHandleLock、 を 3 回呼び出して初めてブロックがロック解除されますMemHandleUnlock。

ネストされたロックとロック解除の問題に対処するのは、さまざまな方法を採用することで簡単ですが (面倒ではありますが)、関連するコード ブロックの可読性が損なわれるため、コーダー側の認識と規律が必要になります。

メモリの「リーク」（割り当ての範囲内で割り当て解除に失敗する）を回避し、解放後の古いハンドルへの参照（通常はハード クラッシュを引き起こします。シングルタスク システムでは厄介な問題で、他のプログラムが実行中の場合は壊滅的な結果になる可能性があります）を回避するためにも、認識と規律が必要です。

状況は、512KB以上のメモリを搭載したMacで複数のアプリケーションを同時に実行できるSwitcherの登場によって悪化した。 ^[7]これは、一度に1つのアプリケーションというアプローチに非常に制限を感じていたユーザーにとっては必要な前進だった。Appleは、既存のアプリケーションとの互換性だけでなく、メモリ管理モデルにも力を入れていたため、各アプリケーションに使用可能なRAMから独自のヒープを割り当てる方式を採用せざるを得なかった。各ヒープに割り当てられる実際のRAMの量は、各アプリケーションのメタデータにコード化された値によって設定され、プログラマによって設定された。この値は特定の種類の作業には不十分な場合があったため、値の設定をユーザーに公開し、ユーザーが自分の要件に合わせてヒープサイズを微調整できるようにする必要があった。「パワーユーザー」の間では人気があったが、技術的な実装の詳細を公開することは、Macユーザーの哲学に反していた。難解な技術をユーザーに紹介するだけでなく、アプリケーションは割り当てられた RAM のほとんどを未使用のままにしていても、その RAM をすべて取得するように作られているため、非効率的でした。別のアプリケーションはメモリ不足に陥る可能性がありますが、別のアプリケーションが「所有」している空きメモリを利用することはできません。^[3]

アプリケーションは他のアプリケーションのヒープを有効活用することはできませんが、通常は意味のないアドレスに誤って書き込むことによって、ヒープを破壊することはできます。アプリケーションがテキストや画像の一部、または割り当てられていない場所を誤ってポインターとして扱うと、他のアプリケーションや OS のコードやデータが簡単に上書きされ、プログラムが終了した後も「潜伏者」が残ってしまいます。このような問題は、分析して修正するのが非常に難しい場合があります。

Switcher は System 4.2 でMultiFinderに進化し、 System 7では Process Manager となり、その頃にはこの方式は定着していた。Apple は明らかな制限を回避するためにいくつかの試みを行った。その 1 つが一時メモリで、アプリケーションはヒープ外にある空き RAM を短期間「借りる」ことができたが、これはプログラマーに不評で、問題の解決にはほとんど失敗した。Apple の System 7 Tune-up アドオンは「最小」メモリ サイズと「推奨」サイズを追加した。推奨メモリ量が利用できない場合、プログラムは最小スペースで起動することができ、機能は制限される可能性がある。これは System 7.1 から標準 OS に組み込まれたが、それでも根本的な問題は解決されなかった。^[8]

未使用のメモリ部分をディスクにページングすることでより多くのメモリを利用可能にする仮想メモリスキームは、Connectix Virtual などのサードパーティ ユーティリティによって利用可能になり、その後、System 7で Apple によって利用可能になりました。これにより、パフォーマンスは犠牲になりますが、Macintosh のメモリ容量は増加しましたが、保護されたメモリは追加されず、一部のポインタを無効にするメモリ マネージャのヒープ圧縮も防止されませんでした。

もともとMacintosh には 128 KB の RAM があったが、はんだ付けされていたにもかかわらず、実際の限界は 4 MB だった。この限界に初めて達したのは、Macintosh Plusとユーザーがメモリをアップグレードできるようになったときだった。これらの最初の数台の Macintosh コンピュータは、物理アドレス ラインが 24 本しかない 32 ビット プロセッサの68000 CPU を使用している。24 ラインでプロセッサは最大 16 MB (2 ²⁴バイト) のメモリをアドレス指定でき、当時はこれで十分だと考えられていた。Macintosh の設計における RAM の限界は、メモリ マップの構造上、RAM が 4 MB、ROMが 4 MBで、残りの 8 MB のアドレスはSCC、IWM、および VIA チップに分割されていた。^{[9] [10]この問題は、} Macintosh IIでメモリ マップを変更して修正され、ROM と I/O アドレスをそれぞれ 1 MB に縮小し、残りの 6 MB のアドレスをNuBusスロットに割り当てることで、最大 8 MB の RAM を使用できるようになりました。Connectix製品のMAXIMA、RAM Doubler、Virtualでは、NuBusカードに割り当てられた6MBのアドレスにアクセスして再割り当てすることができ、占有スロットごとに1MB減って合計14MBになりました。^{[11] [12]}

メモリは希少なリソースであったため、Classic Mac OS の開発者は各アドレスの未使用バイトを利用することにしました。オリジナルのメモリ マネージャ (System 7 が登場するまで) は、各 32 ビットポインタとハンドルの上位 8 ビットにフラグを配置しました。各アドレスには、「ロック済み」、「消去可能」、「リソース」などのフラグが含まれており、マスター ポインタ テーブルに格納されていました。実際のアドレスとして使用された場合、これらのフラグは CPU によってマスクされ、無視されました。^[4]

この設計は、非常に限られた RAM スペースを有効に活用するものでしたが、Apple が 32 ビットのMotorola 68020 CPU を使用した Macintosh II を発表したときに問題を引き起こしました。68020 には 32 の物理アドレス ラインがあり、最大 4 GB のメモリをアドレス指定できました。メモリ マネージャが各ポインタとハンドルの上位バイトに格納したフラグは、今では重要であり、アドレス指定エラーを引き起こす可能性がありました。

Macintosh IIci 以降のマシンでは、HLock()およびその他の API が書き直され、ハンドルの上位ビットにフラグを設定する以外の方法でハンドル ロックが実装されました。しかし、多くの Macintosh アプリケーション プログラマーと Macintosh システム ソフトウェア コード自体は、フラグHLock()を操作するために提供されていた などの API を使用するのではなく、フラグに直接アクセスしていました。これにより、アプリケーションは真の 32 ビット アドレス指定と互換性がなくなり、「32 ビット クリーン」ではないと言われるようになりました。

この問題によってシステムが頻繁にクラッシュするのを防ぐため、68020 または 68030 で動作する System 6 およびそれ以前のバージョンでは、マシンを 24 ビット モードに強制し、RAM の最初の 8 MB のみを認識してアドレス指定していました。これは、ハードウェアが最大 128 MB の RAM を受け入れるように配線され、製品資料でこの機能が宣伝されているマシンでは明らかな欠陥でした。System 7 では、Mac システム ソフトウェアはようやく 32 ビット クリーンになりましたが、ROM のダーティ化の問題は残っていました。問題は、24 ビットまたは 32 ビットのアドレス指定を使用する決定を、ブート プロセスの非常に早い段階で行う必要があることでした。このとき、ROM ルーチンはメモリ マネージャを初期化し、NuBus ROM とディスク ドライバがロードされて実行される基本的な Mac 環境をセットアップします。古い ROM には 32 ビット メモリ マネージャのサポートがまったくなかったため、32 ビット モードでブートすることはできませんでした。驚いたことに、この欠陥に対する最初の解決策は、ソフトウェアユーティリティ会社Connectixによって公開されました。同社の System 6 拡張機能である OPTIMA は、メモリマネージャを再初期化し、Mac の起動プロセスの初期部分を繰り返すことで、システムを 32 ビットモードで起動し、マシン内のすべての RAM を使用できるようにしました。OPTIMA は後に、System 7 用のより馴染みのある 1991 年製品MODE32に進化しました。Apple は 1991 年後半に Connectix からソフトウェアのライセンスを取得し、無料で配布しました。Macintosh IIciおよびそれ以降のMotorolaベースの Macintosh コンピュータには、32 ビットのクリーン ROM が搭載されていました。

アプリケーションが24ビットへの依存をすべて取り除くように更新されるまでにはかなりの時間がかかり、System 7ではアプリケーションの非互換性が見つかった場合に24ビットモードに戻す方法が提供されました。^[3] PowerPCとSystem 7.1.2への移行時には、ネイティブアプリケーションの作成には32ビットクリーンであることが必須であり、その後のMotorola 68040ベースのMacでも24ビットモードをサポートできませんでした。^{[6] [13]}

Mac プログラミング用のオブジェクト指向言語 (最初はObject Pascal、その後C++ )の台頭も、採用されたメモリ モデルに問題を引き起こしました。最初は、再配置可能という利点を得るために、オブジェクトをハンドル経由で実装するのが当然のように見えました。これらの言語は、元々設計されたように、オブジェクトにポインタを使用していたため、断片化の問題が生じました。THINK (後のSymantec )コンパイラによって実装された解決策は、オブジェクトの内部ではハンドルを使用し、それらにアクセスするにはポインタ構文を使用するというものでした。これは最初は良いアイデアに思えましたが、すぐに深刻な問題が発生しました。プログラマーは、再配置可能なブロックを扱っているのか、固定ブロックを扱っているのかを判断できず、オブジェクトをロックするタスクを引き受けるかどうかを知る方法がなかったためです。言うまでもなく、これはこれらの初期のオブジェクト実装で膨大な数のバグと問題につながりました。後のコンパイラはこれを試みず、実際のポインタを使用し、多くの場合、Mac OS のメモリ モデルを回避するために独自のメモリ割り当てスキームを実装しました。

Mac OS のメモリモデルは、固有の問題を抱えながらも、アプリケーションの互換性に関する厳しい制約のため、 Mac OS 9までそのままだったが、安価な RAM が入手しやすくなったことで、ほとんどのユーザーはアップグレードすることで窮地から脱出できるようになった。メモリは効率的には使われていなかったが、十分な量があったため、この問題は深刻にはならなかった。元の設計の目的が、非常に限られた量のメモリを最大限に活用することだったことを考えると、これは皮肉なことである。Mac OS X は最終的にこの仕組み全体を廃止し、最新のページ仮想メモリスキームを実装した。古いメモリモデル API のサブセットは、互換性のためにCarbonの一部としてまだ存在しているが、その下には最新のメモリマネージャ (スレッドセーフなmalloc実装) がマップされている。^{[6] Apple は、} Mac OS Xコードでは「ほぼ排他的に」mallocとを使用することを推奨しているfree。^[14]

• Macintosh: 各種モデルの ROM サイズ、Apple Inc、2000 年 8 月 23 日、2009 年9 月 22 日取得