clibと呼ばれるライブラリー開発の思い出(4)
(前回はこちら)
メモリ管理ライブラリのAPI設計にあたっては、メモリ空間がシステム全体で一つというVxWorks上で、どうやって効率よくメモリ関連の問題を早期に発見するかという視点で設計しました。細かな技術的な詳細は説明しませんが、メモリ管理ライブラリは以下の機能を持つように設計しました。
メモリ管理ライブラリはもちろんスレッドセーフに作成されており、このライブラリに基づいて、共通ライブラリとしてコレクション機能も含む「スレッドライブラリ」を設計しました。「スレッドライブラリ」は、Javaとそのライブラリに強く影響を受けたC++用ライブラリでした。
次回は、「スレッドライブラリ」について簡単に説明します。
メモリ管理ライブラリ
1990年代に開発したFuji Xerox DocuStation IM200 / AS200は、オペレーティングシステムがSolaris 2.3であったため、プロセスが存在していました。つまり、ユーザのメモリ空間に関しては、プロセスの壁があった訳です。それでも、プロセス内でのメモリ破壊のデバッグには苦労しました。メモリ管理ライブラリのAPI設計にあたっては、メモリ空間がシステム全体で一つというVxWorks上で、どうやって効率よくメモリ関連の問題を早期に発見するかという視点で設計しました。細かな技術的な詳細は説明しませんが、メモリ管理ライブラリは以下の機能を持つように設計しました。
- メモリをヒープゾーン(Heap Zone)と呼ばれる大きな単位で扱い、すべてのメモリ獲得は指定された特定のヒープゾーンから行う。用語「Heap Zone」は、初期のMachintoshのAPIから拝借したものです。
- ヒープゾーンから獲得されたメモリブロックを
delete
オペレータで解放する際に、そのメモリブロックの範囲を超えて書き込みをして破壊していないかを検査する仕組み。破壊を検出した場合には、破壊を報告すると同時に、そのメモリブロックをnew
オペレータで割り当てたソースコード名と行番号を表示する。 new
オペレータで獲得されていないメモリブロック(もしくは、誤ったアドレス)をdelete
オペレータで解放しようとしていないかを検査する仕組み。- メモリブロックが獲得されたが初期化されていない、もしくは、解放されたことをデバッガーで調べている時に分かるようにする仕組み(初期化忘れやダングリングポインターに容易に気づく仕組み)。
- ヒープゾーン内の現在のメモリ使用量と最大使用量を知る仕組み。
- メモリリークを容易に検出できるようにし、リークしているメモリ
ブロックがどのソースコードの何行目で獲得されたかを報告する仕組み。
メモリ管理ライブラリはもちろんスレッドセーフに作成されており、このライブラリに基づいて、共通ライブラリとしてコレクション機能も含む「スレッドライブラリ」を設計しました。「スレッドライブラリ」は、Javaとそのライブラリに強く影響を受けたC++用ライブラリでした。
次回は、「スレッドライブラリ」について簡単に説明します。
この記事へのコメント