a22_memo01 のバックアップ(No.9)

a22に関する雑記#1

(by K, 2021.03.29)

2022.03.29(火)

なんか調子が出ないなと思ったら、「そうかa22_memo01を書いてないからだ！」と思いつきました。ということで開始。

今日はacl2ライブラリに追加中の、AMemAlc2というメモリアロケータのテストをしました。これはメモリ効率が良いうえに高速なアロケータなのですが、個別に開放することができません（サイズ変更などもできません）。だからあとでまとめてポイするようなメモリの使い方をする場合に重宝します。

個別にfreeしないのなら、メモリのアロケート処理は簡単になります。まず適当に大きなメモリブロックを持ってきて、それをアロケート要求が来るたびに切り取って渡せばいいだけだからです。そしてまとめて開放するときには、その大きなメモリブロックをfreeしてしまえばそれで終わります。

[テストプログラム: AMemAlc1（普通のmalloc相当）で確保した場合]
AMemAlc0_report0: n=255 total=43456 // 実際の消費メモリ
AMemAlc0_report1: n=255 total=32640 // アラインのためのパディングを除いたもの

[テストプログラム: AMemAlc2で確保した場合]
AMemAlc0_report0: n=3 total=32784 // 実際の消費メモリ
AMemAlc0_report1: n=3 total=32656 // アラインのためのパディングを除いたもの

このテストでは、AMemAlc2を使ったほうがメモリブロック数（n）が少なくて、実際の消費メモリも抑えられています。
- report1の結果は、AMemAlc2のほうが16バイト多いですが、この16バイトは3つのメモリブロックを後でまとめて開放するための管理情報です。

お気に入りのライブラリ
- [AClean]メモリの開放やオブジェクトのdeinitをかなり楽にしてくれるやつ。
- [AMemAlc0]最も基本的なメモリアロケータ。サイズ指定を無視していつも同じサイズのメモリブロックを提供する。高速。
- [AMemAlc1]AMemAlc0を28個たばねて、mallocのような感覚で使えるメモリアロケータ。サイズに合ったメモリブロックを提供する。
- [AMemAlc2]個別の開放を許さない代わりに、メモリの利用効率を改善したもの。

あと、今日はデバッグレベルを2にするとacl2ライブラリがまともに動かなくなってしまうというバグを直しました（デバッグレベルはa22_memman05の(5)で説明しています）。
デバッグレベル2だとオブジェクトのチェック処理が有効になるのですが、チェック処理をするためのオブジェクトがあって、自分自身のチェックをしようとして無限ループになってしまうという問題がありました。少々苦労しましたが、なんとか直せたと思います。

↑

2022.03.31(水)

C言語の場合、確実に参照しない引数が末尾にある場合、それはスタックに積む必要はない（レジスタに代入する必要はない）。でも今はこれを表現する手段がないので、不必要な引数も適当な値を積まなければいけない。HLXではこれをなんとかできたら、わずかな優位性になるかもしれない。

↑

2022.04.02(土)

今までC++のオブジェクトの自動開放（スコープを抜けるとデストラクタがよばれるやつ）がうらやましくてそのことだけを考えてACleanクラスを作ったのですが、これだけではガーベージコレクションには勝てないと気づきました。・・・ガーベージコレクションはcopying GC機能を有しているものがあって、つまりメモリコンパクションができるので、メモリのフラグメンテーションが発生しないわけです。おおなるほど、それはうらやましい。
上記の(2022.03.29)に書いたAMemAlc2をうまく使えば、連続したメモリが解放されるようになるので、そもそもメモリのフラグメンテーションは発生しにくくなります。しかしそれでも、メモリの使い方によっては、「全く発生しない」ということにはできません。たとえばオンメモリのデータベースがあって、データの挿入と削除を繰り返せば、徐々にフラグメンテーションは発生するでしょう。
ガーベージコレクションを実装せずに、同等の機能を実現するにはどうしたらいいかを考えました。それは結局、copying GC的なことを自前でやるしかなさそうだと思いました。たとえばオンメモリデータベースクラスを作ったとしたら、データベースオブジェクトを複製するメンバ関数を作るべきで、それを使うことで古いデータベースから新しいデータベースを作ることができて、そのあとで古いほうを消してしまえばいいわけです。
このときメモリアロケータをわければ、新しいほうが最初から断片化してしまう問題は生じないでしょう。
ちなみにacl2ライブラリでは、標準のAMemAlc1の上にAMemAlc2を載せて、そのAMemAlc2の上にAMemAlc1を載せる、みたいなことができます。こうすることで、メモリの確保と解放が自由にできて（これは最上位のAMemAlc1の機能によるもの）、しかもその使用範囲は連続的かつ限定的で（これはAMemAlc2によるもの）、完全に使い終わったらAMemAlc2の機能で一括解放が可能です。

↑

2022.04.03(日)

HLX-003cをacl2ライブラリに対応させて、コンパイルが通るようになって、テストランしてみたら、よしよし動く。・・・それで試しにデバッグレベルを2にしてみたら、a=1;すら内部エラーになってしまう。・・・え？なんということ！
これ、もし本当にバグを見つけてくれているのだとしたら、すごく役立っていることになるのだけど、一方で、そんな初歩的なミス（＝デバッグレベルを上げた程度で検出できるバグ）をしていたなんて、我ながら情けない・・・。今はまだバグ検出ルーチンのバグなんじゃないかと思っています。
ちなみにデバッグレベル0でも、行数の多いプログラムを実行すると落ちるので、やはりどこかおかしいのは間違いないです。acl2対応の時にミスったのかなあ・・・。

↑

2022.04.04(月)

本当にバグでした。ただし、間違っていたのはHLXではなくて、acl2の中身でしたが。まあとにかく、バグを早く見つけて直せたので良かったです。

さて、改良を始めると止まらなくなるので、まずはいったんこのあたりで公開かなあ。

↑

こめんと欄

コメント	お名前	NameLink