以前 、tamarinが難しいと書きましたが、
ミキタ先生が解読されておりました。ばんざーい。
しかも実験的branchであるTamarin Tracing(TT)を解説しておられます。
http://dodgson.org/omo/t/?date=20080506

保険版(安定版)であるTamarin Central(TC)は
http://dodgson.org/omo/t/?date=20061111
に解説があります。

違いは、TCは基本的に全てnative codeに変換するのに対し、
TTはループ等の必要な部分だけnative codeに変換するところです。

1,2回しか実行しないスクリプトをわざわざnative codeに変換して実行しても、
変換コストが大きいので遅くなるだけです。
TTはそういったスクリプトは変換しないので、TCよりも高速に動作することが期待されます。 *0

というと凄そうですが、Java VMではそういった最適化はとっくの昔に行われており、
意地悪な言い方をすれば、ECMAScript(JavaScript,ActionScript)の実装の世界は、
Javaの劣化猿真似の領域を出ていないのかもしれません。
あ、だからどれもなんとかMonkeyってプロジェクト名なのか？(おい)

さて、僕がSpiderMonkey(FireFox 3までのJS実装)はなんとか読めるけど、
Tamarin(FireFox 4のJS実装)は読みにくいと思ったひとつの新たな理由に気づきました。

TamarinはECMAScript4じゃん！
いわゆるJavaScript2.0です。
そんな仕様知らんよ。

ということで調べました。
http://www.mozilla-japan.org/events/2007/javascript/tamarin-es4.pdf
http://www.ecmascript.org/es4/spec/overview.pdf
あたりを見るとよく分かります。特に上のスライドが分かりやすくてお勧め。

どうやら、プロトタイプベースオブジェクト指向で非常にシンプルで
美しいと好評のアーキテクチャに、C++やJavaでお馴染みの
クラスベースオブジェクト指向を取り入れるのが主な趣旨なようです *1 。

せっかくの美しさが…と嘆きたくなるかもしれませんが、
これには主に2つの思惑があるのかな？僕の勝手な推測だけど。

• クラスベースで設計するプログラマを取り込みたい
• 実行速度を稼ぎたい

まず、クラスベースの設計ができるようになれば、C++,Java組からの敷居が一気に低くなります。プロトタイプベースは最初は気持ち悪いし、面倒くさくてやる気にならない人も多いのではと思います。というか僕がそうです。
気持ち悪いのは、型がないのでコンパイル時に未然に防げるバグも通ってしまうとか、そういった理由です。

それから、プロトタイプベースは実行速度がどう頑張っても稼げません。
例えば、C++やJavaなら型があるので、実行時にまずメンバ関数のアドレスがほぼ静的に決定できます。
仮想関数だったとしてもvtblを引くだけです。たかだか1,2語native codeが増えるだけです。
メンバ変数もインスタンスの先頭アドレス+オフセットで表現して機械語に落ちますから、
基本1,2語のnative codeで参照できるわけです。

ところが、プロトタイプベースではそうはいきません。
殆どが動的に決定されるので、プロパティやプロトタイプを使う度に、
毎回連想配列を引く必要があります。
つまり、せっかくJITでnative codeに落としてみても、
たかだかメンバ変数のひとつの値を参照するためだけに、
インタプリタと全く同じ連想配列を引く関数をコールする羽目に結局なるのです。
これではJITの意味がない。
そりゃフィボナッチとかFFTとか数値演算で閉じた関数には効果があるかもしれませんがね、
一般的なコードには効き難いでしょうよ。

これは無駄すぎだよねえ… *2 。
jsが生まれた当時の想定を遥かに越えて利用範囲が広がってしまった今、
ECMAScriptの言語としてのTDPを考える時代がそろそろ来てるんじゃないでしょうか。

おっと、それはどうでもいい。
とにかくクラスベースで組める様になれば、理論上はJava VMに匹敵する性能、
つまりC/C++で書いたコードに匹敵する性能が得られる可能性があるわけです。
そうすれば、今までC/C++やJavaで書いていたアプリをJSが駆逐する可能性が出てきます。
webからデスクトップガジェットへ、そしてアプリケーションへ。
JSの進化はOSを駆逐する可能性があります。


つーか、それなら初めからJavaでいいじゃん？って思った人は多分正解。