clibと呼ばれるライブラリー開発の思い出（４）

（前回はこちら）

メモリ管理ライブラリ

1990年代に開発したFuji Xerox DocuStation IM200 / AS200は、オペレーティングシステムがSolaris 2.3であったため、プロセスが存在していました。つまり、ユーザのメモリ空間に関しては、プロセスの壁があった訳です。それでも、プロセス内でのメモリ破壊のデバッグには苦労しました。

メモリ管理ライブラリのAPI設計にあたっては、メモリ空間がシステム全体で一つというVxWorks上で、どうやって効率よくメモリ関連の問題を早期に発見するかという視点で設計しました。細かな技術的な詳細は説明しませんが、メモリ管理ライブラリは以下の機能を持つように設計しました。

• メモリをヒープゾーン（Heap Zone）と呼ばれる大きな単位で扱い、すべてのメモリ獲得は指定された特定のヒープゾーンから行う。用語「Heap Zone」は、初期のMachintoshのAPIから拝借したものです。
• ヒープゾーンから獲得されたメモリブロックをdeleteオペレータで解放する際に、そのメモリブロックの範囲を超えて書き込みをして破壊していないかを検査する仕組み。破壊を検出した場合には、破壊を報告すると同時に、そのメモリブロックをnewオペレータで割り当てたソースコード名と行番号を表示する。
• newオペレータで獲得されていないメモリブロック（もしくは、誤ったアドレス）をdeleteオペレータで解放しようとしていないかを検査する仕組み。
• メモリブロックが獲得されたが初期化されていない、もしくは、解放されたことをデバッガーで調べている時に分かるようにする仕組み（初期化忘れやダングリングポインターに容易に気づく仕組み）。
• ヒープゾーン内の現在のメモリ使用量と最大使用量を知る仕組み。
• メモリリークを容易に検出できるようにし、リークしているメモリ ブロックがどのソースコードの何行目で獲得されたかを報告する仕組み。

今日では、このようなことを気にしないといけないような言語で開発することは少なくなっていると思います。しかし、2000年の頃、C++による大規模な組み込みシステムの開発では、これらの機能を事前に用意していないと、メモリ関連の障害によるデバッグは大変な時代でした。今から、やり直せるとしたら、C++ではなく、Go言語で作り直すと思います（訳者あとがき『プログラミング言語Go』）。

メモリ管理ライブラリはもちろんスレッドセーフに作成されており、このライブラリに基づいて、共通ライブラリとしてコレクション機能も含む「スレッドライブラリ」を設計しました。「スレッドライブラリ」は、Javaとそのライブラリに強く影響を受けたC++用ライブラリでした。

次回は、「スレッドライブラリ」について簡単に説明します。