不連続都市伝説シリーズ:malloc()は断片化による性能悪化をtypicalには避けられない

 

ドラクエXのエアプレイヤーであるごみためまんは、つい先日プレイ動画のリコメンドメールを受け取りました。

なぜかそのリンク先のリコメンド動画に以下のmalloc解説動画が含まれていました。

 

でまぁ眺めた後でスライドを確認、と。

Glibc malloc internal

ビミョーにバージョンがが違うぽい・・・

個人的には

mallocのメモリ断片化には注意

と偏った考えを抱えていたので、glibcの実装を知って若干目から鱗でした。

# 誰かに担がれたんでしょうな

 

何しろ私のmallocについての肌感覚はK&Rレベルですんで。

例えばそれを基に以下のように騙っていたことがあります。

ごみため(ー日ー膳!)+- 他人に見えないものが見える

私にはキミに見えないものが見えるんだ。例えば,static int a[10];と書いたら,a[0]の1ワード前のアドレスにサイズを示す「10」が書いてあるんだ。それをキミは見たことがあるかい?例えばsizeof演算子はこの数字を返すだけさ。それが見えるようにならないとICEで闘うことなんてできないよ。

で、先に挙げた動画やスライドを見れば、mallocで生成した配列のバイトサイズが書いてある様子が、大変よくわかるでしょうね。

上記で騙りのポイントは、「static int」である点です。

それと「ニューロマンサー」読んでれば「ICEで闘う」に反応するシトがいるんじゃないですかね。

 

***

ここでちょっとコラム

動画の説明でも繰り返し変態的な構造体の使い方について

説明がありますが、

Cの大規模プロジェクトでは

必ずこの手の可変長要素を含む構造体が出てきたものです。

ガチャピン先生も組み込み系のご出身のようなので

たぶん免疫がおありになるのでしょう。

「PDPの時代にはCPUキャッシュがなかった」

というセリフには

「PDP-11の途中くらいからCPUキャッシュあったみたいっすよ」と重箱の隅をつついておきます。

可変長要素の構造体というのは、

慣れてしまえば素晴らしいものです。

バグの生成工場になりがちですが。

***

 

もう一つ思い出したのは、昔某MOAP周辺で

チャンクサイズ別のmallocの実装

を見かけたことです。組み込みで動的メモリ管理はまだ法度な感じだったので、結構衝撃だった気がします。

限られた共有メモリにでかい画像イメージと細かいデータが共存するので断片化が致命的なのが理由のようでしたが。

 

***

ガチャピン先生の動画を何年もたってから無断で引用すると叱られる習わしがあるようですが、これは引用ではない何かなのできっと大丈夫。

 

リンクる:

malloc(3)のメモリ管理構造 – VA Linux Systems Japan株式会社