a24_AMemMan のバックアップ(No.3)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
a24_AMemMan へ行く。
- 1 (2024-09-13 (金) 10:56:21)
- 2 (2024-09-13 (金) 13:47:24)
- 3 (2024-09-13 (金) 23:20:09)
- 4 (2024-09-14 (土) 03:05:59)
- 5 (2024-09-14 (土) 07:59:11)
- 6 (2024-09-14 (土) 07:59:11)
- 7 (2024-09-14 (土) 07:59:11)
- 8 (2024-09-14 (土) 07:59:11)
- 9 (2024-09-20 (金) 01:19:19)
- 10 (2024-09-20 (金) 15:49:09)

AMemMan （メモリ管理）

(by K, 2024.09.13)

↑

(0)

標準関数のmalloc/free/realloc/callocがあまり使いやすくない気がするので、自分で作ってみました。

↑

(1)

[自動開放#1]
当たり前ですが、メモリを確保したら使い終わった後に開放しなければいけません。しかしたまに煩雑になってやり忘れます。そうするとそれはメモリリークになります。
```
p0 = malloc(size0);
p1 = malloc(size1);
p2 = malloc(size2);
...
free(p2);
free(p1);
free(p0);
```
上記は簡単な例で、これで間違えるようではプログラミングの適性がないのではと疑われるレベルですが、しかしmallocが並んでいなくて、mallocするかしないかが条件によって異なるとかになってくると、だんだんfreeし忘れのリスクが出てきます。

もしこれがこう書けるようになったらいいと思いました。

p0 = malloc_autoRelease(size0);
p1 = malloc_autoRelease(size1);
p2 = malloc_autoRelease(size2);
...
release();

これはmallocしたときにその情報が記録され、release()ではその情報をもとに正しい順序で（＝登録とは逆順で）解放します。こういう仕組みがあれば気を張ってなくてもメモリリークはしません。プログラムを改造してmallocが増えても大丈夫でしょう。

[自動開放#2]
メモリ開放だけではなく、オブジェクトのデストラクタ呼び出しなどもやり忘れる可能性があります（それを全部自動でうまくやってくれるのがC++なのですが）。だからこういうこともできます。
```
p0 = malloc_autoRelease(size0);
p1 = newObject_autoRelease(...);
...
release();
```

さらに、自動管理の範囲も設定したいです。

void myFunc()
{
    ARP *pool = newAutoReleasePool();
    p0 = malloc_autoRelease(pool, size0);
    p1 = newObject_autoRelease(pool, ...);
    ...
    releaseARP(pool);
}

こうすればmyFuncを呼ぶ前にautoReleaseしたものは、releaseARP(pool)では解放されません。つまり自動開放プールは複数つくることができて、malloc時にどのプールに登録するか選べるのです。

[メモリ確保・解放のアルゴリズム選択]
標準のmalloc/freeは汎用的に作られてはいますが、使われ方によっては十分な性能がでません。つまりあまり速くない場合があるのです。そんな場合、確保や解放のアルゴリズムが別のmalloc/freeを使えば、十分な性能が出るようになります（分かりやすいようにあとでベンチマーク例を示します）。
一つのアプリの中に複数のmallocアルゴリズムが共存できます。標準のmalloc/freeをそのまま使うだけのアルゴリズムA、別のアルゴリズムB、さらに別のアルゴリズムCがあったとして、Bはメモリが足りなくなるたびにAに追加のメモリを要求して、自分の管理下にあるメモリだけを管理すればいいのです。Cも足りなくなればAからメモリをもらえばいいのです。そしてBやCは管理が終わったメモリをAに返します。・・・こうして複数のメモリ管理アルゴリズムが競合せずに共存することになります。

[統合]
それでこのメモリ管理アルゴリズムの選択と自動開放プールの両方を統合して、AMというクラスを作りました。もとはAMemManという名前でしたが、使用頻度が非常に高く、短い名前の方が便利だということになってこうなりました。
これにより、たとえば二分木アルゴリズムのように適宜mallocやfreeをするライブラリは、オブジェクト生成時にAMのポインタを渡すことになりました。そうしないとどうやってmalloc/freeしたらいいか指定できなくなるからです。これらのクラスライブラリは、AMのポインタを自分のオブジェクト内に覚えておいて、必要に応じて使います。だからメソッド関数を呼び出す際に指定する必要はありません。

この構造になるとデバッグがやりやすいです。デバッグ対象に渡すAMには、例えば「合計容量が1MBを超えたらわざとout-of-memory（＝NULL）を返すようにする」のような小細工を簡単に入れられます。malloc/freeのログを取らせることもできます。malloc/freeに不整合がないか厳密に確認することもできます。こうして、メモリ不足になった時の挙動の確認や、メモリリークをどこで起こしているかの調査など、色々なことができます。

↑

(2)

(2-1)例えばこういうコードは、標準のmalloc/freeの苦手なパターンです。

void func21()
{
    int i, n = 1000000, **a = malloc(n * sizeof (int *));
    for (i = 0; i < n; i++)
        a[i] = malloc(64);
    for (i = 0; i < n; i += 2)
        free(a[i]); // 偶数番目だけを先に開放.
    for (i = 1; i < n; i += 2)
        free(a[i]); // 奇数番目をその後に開放.
    free(a);
}

(2-2)これに対してこういうコードを書くことができます。

void func22(AM *m2, AM *m)
// m2は64バイトの確保・解放のみに特化したメモリ管理アルゴリズムを想定.
{
    int i, n = 1000000, **a = AM_alc(m, 0, n * sizeof (int *));
    for (i = 0; i < n; i++)
        a[i] = AM_alc(m2, 0, 64);
    for (i = 0; i < n; i += 2)
        AM_fre(m2, a[i], 64);
    for (i = 1; i < n; i += 2)
        AM_fre(m2, a[i], 64);
    AM_fre(m, a, n * sizeof (int *));
}

(2-3)速度の比較

func21()	0.234秒	mallocとfree
func22(am0, am0)	0.237秒	am0はmalloc/freeをそのまま使うだけのアルゴリズム、オーバーヘッドが増えた分だけ少しだけ遅い
func22(m2, am0)	0.065秒	m2は64バイトのメモリを高速に管理できるアルゴリズム、func21よりも3.6倍速い結果になった

↑

a24_AMemMan のバックアップ(No.3)

AMemMan （メモリ管理）

(0)

(1)

(2)

(3) ver.1.00 [2024.09.13] (？行)