BSD Conference 2006 Canadaは、前日までの空模様とはちがって雨の中での開催となった。前日までは開発者中心のサミットだったが、12日(東部標準時)からはBSDCanである。選考に通過した選りすぐりの論文が発表がおこなわれる。

雨の降りしきる Ottawa, Canada

降りしきる雨もまったく関係ないかのように、BSDCanの会場は関係者の熱気で包まれていた。参加者に開発者以外も多いためか、開会式はジョークも飛び交う和やかな雰囲気である。ラウンジで歓談している関係者も多い。初見の方が多いとはいえ、お互いの名前はメーリングリストやIRC、Web媒体を通じてよく知っている。初めて合う相手なのに、案外自分の名前が相手にも知られているというのはなんとも妙な気分だ。

サロンのような雰囲気のあるBSDCanだが、一度発表がはじまるとなれば聴講者は真剣そのものだ。ここから多くの知識を仕入れていこうと、発表がはじまったとたんに顔色がかわる。ここにいる方々はみなが第一線で活躍している一級のFreeBSDユーザたちである。

以降では、BSDCan 2006のうち、とくに興味深いと感じたセッションをとりあげて紹介する。どれも今後のFreeBSD開発において重要な技術となっていく可能性がある。トラックが3並列で進行しているため聴講できないセッションが多かったが、とくにFreeBSDのコアに関与してくる技術や重要度の高いとおもわれるものを中心に選択したつもりだ。今後の方向性を感じていただければ幸いだ。

BSDCan 2006 開会式

A Scalable Concurrent malloc(3) implementation for FreeBSD

FreeBSDデベロッパであるJason Evans氏からは、同氏が開発した新しいmalloc(3)実装であるjemallocに関する技術発表がおこなわれた。本セッションの注目度は高く、多くのFreeBSDデベロッパが聴講にきていた。

FreeBSDデベロッパ, Jason Evans氏	FreeBSDデベロッパ, Poul-Henning Kamp氏 – 自分の開発したmalloc(3)実装の性能評価を最前列で興味深く聞き入っている

FreeBSDの従来のmalloc(3)実装は、マルチプロセッサシステムにおいてはコンテンション、キャッシュスライシング、キャッシュラインシェアリングといった点において性能がよくないことがある。これを改善するべくJason Evans氏によって開発された新しいmalloc(3)がjamallocである。すでにFreeBSD 7-currentには統合されている。

malloc(3)はヒープにおいてメモリを確保する関数であり、OSの性能そのものに直接を影響をあたえる要素のひとつとなる。また、malloc(3)は基本的なAPIである。上位レベルのAPIと比べた場合、つぎのような問題がある。

• バウンドチェックをしない(これはC言語の問題)
• 一度獲得したメモリ領域を伸長することができない
• オブジェクトの使い方やライフタイムを指定することができない
• デバック機能が不足している

こうした問題を部分的に解決する方法はある。バッファオーバーフローのキャッチ、malloc_usable_size()の使用など。しかし、方法論としての統一性がなく、繁雑とした状況になっている。

こうした問題を解決するべくすでにいくかの実装が存在している。代表的なものは次のとおり。

• dlmalloc
• ptmalloc
• Hoard
• phkmalloc
• lkmalloc
• libumem
• Vam

それぞれのmalloc(3)実装にはそれぞれの特徴があり、利点と欠点がある。まずはそれぞれに評価をおこない、次の方向性をとらえることが重要になってくる。これまでFreeBSDで使ってきたmalloc(3)はPoul-Henning Kamp氏が開発したphkmallocともいえるものだ。同氏はFreeBSDデベロッパの顔ともいえる存在であり、FreeBSDテクノロジの重要な部分の実装を手がけている。

jemallocでは、phkmallocが抱えている問題を解決するべく、マルチプロセッサ用に設計されたmalloc(3)実装から技術を借用し、いいとこどりにしたようなモデルになっている。

mutexをベースにした実装に変更した場合、コンテンションの発生ということがシステム性能に対して影響を及ぼすようになる。コンテンションとはロック部分で待ちが発生することだ。mutexを使った実装に移行したあとは、できるだけロック部分で待ちが発生しないようにロック順序の変更やロック単位の変更などをおこなってチューニングをする必要がある。

phkmallocはもともとシングルプロセッサシステムが主流だったときに開発された実装であり、マルチプロセッサやmutex実装時における性能は考慮されていない。マルチプロセッサ時代のmalloc(3)への改良が必要になったわけである。

dlmalloc, phkmalloc, jemallocを比較したベンチマークが示された。

ベンチマークの結果からは、jemallocではフラグメントが発生しすぎるという問題が明らかになったが、そもそもそのベンチマークにあまり意味がなかったかもしれないという意見も述べられていた。このベンチマークの目的は論理的な推論と実際の結果が同じになるかどうかを調べることにあったが、不可解な点もあった。malloc(3)は限定されたベンチマークでは実際のシステム性能を測定することができない。キャッシュシステムなどほかのサブシステムに影響される点も多く、フェアな比較ができない。

また、realloc(3)を繰り返すような効率の悪い実装による悪影響がそのままベンチマークに表われている可能性もあり、このベンチマークからは詳しいことがわからないという意見が述べられた。

マルチプロセッサシステムにおけて性能を発揮するには、マルチプロセッサシステムの特性に対応したmalloc(3)実装が必要だ。jemalloはすでにFreeBSD 7-currentに採用されており、今後の展開によってはFreeBSD 6系にバックマージされる可能性もある。今後も評価と改善がおこなれる部分といえる。