読んだ論文をメモしておく - Backnumbers: Steps to Phantasien

2005-05-04

近況

読んだ論文をメモしておく.

最近読んだ論文: Hoard: A Scalable Memory Allocator for Multithreaded Applications

マルチスレッド、マルチプロセッサの環境で効率的に動くメモリアロケータの実装について.

基本的なアイデアは, スレッド毎(プロセサ毎)にメモリブロックをキャッシュするというもの. スレッド間でメモリブロックを共有すると, 排他制御のオーバーヘッドや False Sharing(スレッド同士が CPU のキャッシュを殺しあう現象)が頻発して遅くなるが, スレッド毎のキャッシュをもつことでそういう問題を回避できるらしい. 実際には他にも問題はあって色々やっているのだが, だいたいそんなかんじ.

これをよんだきっかけは, Google Code で公開されていた perftools 付属のメモリアロケータ実装. The fastest malloc we've seen などと主張しているのでどんなものかとドキュメントを読んでみたら, マルチスレッド/マルチプロセスの環境で速いという話だった. これも Hoard 同様スレッド毎にキャッシュを持つことで高速化をしている. 似たような話がないかと探して上の Hoard をみつけた次第.

perftools の文書では ptalloc という実装との比較は載っているが, Hoard とは比較されていない. ぜひ対決してほしい. 外野の要望.

最近読んだ論文: XJ: Facilitating XML Processing in Java

XML を Java の first class object として扱えるようにしましょうという話. 実装もあり, alphaWorks 内からダウンロードできる．(試してない.)

主に以下のような拡張がある.

XML Schema を Java の pakcage のような感覚で import できる.

XPath が文法に build-in されている.

XML をコード内にうめこめる.

ざっと見ていく.

XML Schema を Java の pakcage 感覚で import できる.

たとえば本文中の例だと, "po.xsd" という schema のファイルがあった時

import po.*;

と書ける. そうするとその Schema の Java binding がコード内からアクセスできるようになる. 要するに Relaxer とか JAXB みたいなのが言語に組込まれるということらしい. XML 由来のオブジェクトには toXML() というメソッドがあって, これで文字列化する. 読み込むメソッドもある. そういう (de)serialize のタイミングで Schema の検証をおこない, 変な XML ができるのを防ぐという. (このへんは Relaxer/JAXB も同じだから, 結局は直接 schema を import できるというのが新しいということになる.)

XPath が文法に build-in されている.

これは Perl や Ruby の正規表現みたいなものだと思えばよさそう. 言語に組込む最大の利点は文法をチェックしてくれることかな. 文法はこんなかんじ(本文からコピー):


Sequence<item> bulkPurchases =
  po[| /item[quantity > $discQuantity] |];

"$" を使って Java の変数を参照する. なかなか自然でよい. あれば使う気がする.

XML をコード内にうめこめる.

例:


USPrice price = new USPrice(<USPrice>4.95</USPrice>);
item cup order =
  new item(<item partNum='456-CU'>
              <productName>cup</productName>
                 <quantity>12</quantity>
                    {price}
           </item>);

コードのミタメは衝撃的だ. XML の中にコードを埋めこむ仕組みは PHP の系列で色々あるが, これはその逆. 文字列でなく XML である利点は, コンパイル時に妥当性チェックができることかな. これの便利さはいまいちわからない. 使うんだろうか...

XML が言語の一部になると便利というのはわかった. ただ Java よりもスクリプト言語にくっつけた方が有難味は大きい気がする. たとえば schema の import などは, 開発環境に統合されていれば十分. Java はどうせコンパイルするので, build の中で schema の build もすればいい. 言語内に XML をハードコードするのも, むしろスクリプトでやっつけ仕事をするのに重宝しそうだ. たとえば ruby と eruby を組み合わせて何かするような場面でこれが使えたら便利に違いない.

こんな機能が Groovy にあったら使うな. 彼らは GPath というオブジェクトグラフ検索言語のようなものを提唱しているけれど, これの代わりに XJ のような拡張があったら XML 処理用スクリプトとして決定打になると思う．

なお, related works によれば似たような研究は多いらしい. ECMAScript だと E4X, C# だと Comega というのがあった.