2009-12-21
前置き。dlmallocについて書くぞ！と言っておいて書いてなかったので。orz...すみません。 あろけーたをじぶんでかいてはいけません！！ なぜ、って大抵糞だからです。 例えば、こんな管理構造を持ったアロケータをよく見るんですが、 typedef struct _Allocator { unsigned char* pPool; // メモリプール int nPoolSize; // メモリプールのサイズ struct _SMemChain* pHead; // 番兵 struct _SMemChain* pTail; // 番兵 struct _SMemChain* pLast; // 最後に追加されたチェインタグ } Allocator; typedef struct _SMemChain { struct _SMemChain* pPrev; // 前のチェインタグ struct
ダンプを読めば世界がみえる - 神様なんて信じない僕らのために
dlmallocを読み下し中。 何をしているかは大体解った。 メモリブロックに対して何かを行おうとするプログラムを読み解くとき、 メモリダンプを眺めるということが、 非常に有効だと思った。 プログラムの、メモリの海を見るために必要なのはやはりメモリダンプだ。 メモリをeeとかffとか適当な値で埋めておいて、 ある関数をコールして、 戻ってきたら海を眺める。 そうすると、海には着実な変化が訪れている。 こいつはサイズ（インテジャ）だな、 こいつはアドレスだな。 色んなことがそこには見える。 dlmallocの何が素敵かって、 メモリブロックサイズが4の倍数であることに目を付けて、 0ビット目には一つ前のチャンクの情報の有無を、 1ビット目には使用か未使用かのフラグを設けたことだ。 これはRubyの実装などでも行っていることだけれど、 こうしたことに気が付く人たちは本当に凄い、と思う。 ドキド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
