ブロックサイズが可変で管理する場合の問題点

■加減サイズブロック
獲得と解放を繰り返すうちにメモリの管理が細分化されすぎてしまうということをフラグメンテーションと呼びます。

そんな可変で領域を払いだした領域はリンクリストで繋がっているわけですがもちろん空き領域を検索して再利用するために必要な処理です。

検索処理は目的のものが見つかるまで繰り返し調べるという作業で見つかるまでどのくらいの時間がかかるか保証できません。

この時間保証ができない点がポイントです。

OSにリアルタイム性が求められ「特定の処理が必ず一定時間でおわること」が要求された場合、このような管理は致命的です。

処理に時間がかかること自体も問題なのですが、どのくらいの時間がかかるのかよそくできないことがリアルタイム性という意味で大きな問題です。

リアルタイム性でなくても短い時間で処理したいという場合やはり検索処理は適切でないです。



■固定サイズブロック
メモリ利用効率は悪くなります。

たとえば16バイトを10個、128バイトを5個、1024バイトを3個の固定サイズブロックを作成したとします。

129バイトの領域がほしいと申請した場合、1024バイトが割り当てられるので1000バイト弱無駄になります。

検索がないというのが一番のメリットです。

リンクリストをサイズごとに、さらに、メモリ獲得領域とメモリ未獲得領域のそれぞれを管理すればよいからです。

そのため必要なサイズのリンクリストの先頭を取得すればよいわけですから、検索はありません。

いつ終了するかわからないということもないしリアルタイム性を確保できるし高速な処理にも向いています。

それなので把握できるかわからないのですが、あらかじめそのOSがサポートするメモリブロックの大きさを把握しておいてアプリケーションとしては設計に望んだほうがシステムを無駄に使わないことにつながるのかなと思います。OSの勉強する必要もここいらへんにあると思います。

ヒープ領域

切り出し用のメモリ領域を静的領域として確保します。

KOZOSではそれをリンカスクリプトで定義しますが、このメモリ領域をメモリプールと呼びます。

メモリプールをどう利用すれば効率よく管理できるかが設計のポイントです。

管理しなくてはいけないことを列挙すると以下のようになるかと思います。

・メモリ領域が使用されているかいなか
・どのくらいの大きさの領域をタスクが要求してきて確保すればよいのか


■対するKOZOS設計
・メモリブロックを固定長で何個か用意する
・メモリブロックにヘッダ情報を付加しブロックのサイズ情報などを管理する
・獲得領域と解放済み領域のメモリブロックをリンクリスト管理でそれぞれ管理するが、ヘッダ情報に双方向リンクで管理できるようにする。

このような静的メモリをメモリプールとして漠然と切り出したものに管理機能を付加してメモリを混乱なく使用できるようにしたメモリ領域のことをヒープ領域と呼びます。


でもKOZOS設計でなんで以下の設計が必要なのか迷われた方がいると思います。
・メモリブロックを固定長で何個か用意する

次で説明しますが、リアルタイム性を意識した観点の設計になります。
もし固定長で何個か用意しない場合、どのような問題は起こる可能性があるのか示して行きたいと思います。




リアルタイム性って資源をいかに徹底的に管理できるかということなのかな。

動的な情報のメモリ管理

動的に情報をメモリに保持する設計思想は２つあり、それぞれの領域を区別します。

スタック領域：メモリ獲得と解放が階層的に行われる前提のメモリ領域
ヒープ領域：双方向リンクにより管理された可変サイズのメモリ領域


スタック領域の取得解放はすでに実行形式ファイルをのなかに自動で実現しているものがあるわけで、アセンブラでそのイメージはスタックポインタを用いながら見てきたし、アセンブラで割込み・スレッド実装するときにもアセンブラ記述しながら見てきたわけです。


今回はヒープ領域のほうを実現していくことになります。
静的にメモリ領域を確保しておいて、それをいくつか分割管理しておき、そこにヘッダをつけたリンク構造で管理するものになります。