ElectricalFireコンパイラ
Frequently Asked Questions
著者: Scott
Furman
Last Modified:
ElectricalFire とは何ですか?
ElectricalFire (EF) is a Java 仮想機械 (JVM) - Java プログラムを実行するエンジンです。他の多くの JVM と同様に、EF はより速い性能のために Java クラスファイルをネイティブの機械コードにコンパイルします(Java のソースコードコンパイラは Java プログラムを Java クラスファイルに収められている中間バイトコードに変更するために使われます)。 EF のコンパイラは、最初に実行されるときまでコードをコンパイルしないので、 JIT (Just-In-Time、ジャストインタイム)コンパイラです。
JIT とは何ですか?
JIT は "Just-In-Time compiler"(訳注:「ジャストインタイム コンパイラ」)の略です。ここには Java JIT がいかに動作するかがあります: Java コードがとある Java メソッドを呼び出しかつそのメソッドがそれまで呼び出されていなかったとき、コンパイラがクラスファイルをネットワークかファイルシステムから読み込んでそれを機械コードにコンパイルするまで呼び出しは中断されます。コンパイルが完了した後で、実行は新たにコンパイルされたメソッドから再開します。コンパイル過程は Java プログラムには完全に透過的です(メソッドが最初に実行されるときの遅延をのぞいて)。
JIT コンパイルは既存のバッチ処理コンパイルより優れています、それは:
- メソッドのオンデマンドでのコンパイルを許します。使われないメソッドはまったくコンパイルされません。
- プラットホーム依存の実行形式ではなくプラットホーム独立の Java クラスファイルを配布することを可能にします。
- ネットワークから読み込まれるクラスの場合、 Java プログラムは全体が読み込まれる前に起動できます。
- コンパイラが走っている間はプログラム実行の中断を引き起こす。これらの細かな中断は往々にして積み重なるとかなりのものになり、N動時の遅延 かプログラムの「ぶちぶちの」実行を起こすことがあります。
- JIT はコンパイラが JVM の一部として配布され実行されることを要求し、さらに、コンパイルを実行するためにより多くのメモリを消費します。
- JITコンパイルはバッチ処理コンパイラが生成するコードと同等に速いコードを生成できないかもしれません。バッチ処理コンパイラが用いる最適化技法は JIT が用いるには遅すぎることと、最適化を決める -例えばインライン化- 際にコンパイルが逐次的に進むなら用いることのできる広域情報が用いることができないことの両方があります。
ElectricalFire は Sun の JDK の移植ですか?
ElectricalFire のどこにも Sun の JDK のソースコードは使われていませんし、将来も許されないでしょう。
ElectricalFire がサポートされるプラットホームは ?
短い答え:
現在、x86 Linux と Windows 95/98/NT だけがサポートされています。
長い答え:
正しくは、最初に尋ねる質問は「ElectricalFire (EF) はどのプラットホームをサポートしますか ?」です。EF は、コンパイラの「バックエンド」とアセンブリによるいくらかのサポートコードを書くことでどのアーキテクチャにも比較的容易に移植できるように設計されました。EF ソースコードリリースは、比較的完成している x86 向けバックエンドと、とても未完成の Power PC と HP PA-RISC と SPARC 向けバックエンドを含んでいます。次に、あなたの OS が Java 実行ライブラリによってサポートされているかどうかを問わなければなりません。ElectricalFire の実行ライブラリが現在はあまりに未完成なので、それはまだアカデミックな質問です。
ElectricalFireの現状は ?
このプロジェクトはちょうどおもしろくなり始めたところです。x86 マシンの上では、 Java Compatibility Kit (JCK) にある実行テストの 90% にパスし、 Java 自身で書かれた Java コンパイラの javac を動かすことができます。
java.lang と java.lang.reflect のサポートは堅牢ですが、完成にはほど遠いです。java.io の基礎的サポートが利用できます。ほぼ他の全てのクラス -例えば AWT- は、VM のネイティブコードとの統合を必要とするのでまったく動きません。(かつて EF が商業製品だった頃、私たちは高機能なライブラリを実装するほぼ全てを Sun JDK1.2 のクラスとネイティブコードに依存していました。)私たちは、フリーな Java クラスライブラリの作業を進めているグループの一つ、Classpath プロジェクトのような、と Java 標準クラスを加えるためにともに作業するつもりです。後から飛び込んできたニュース: Sun による新しい Java ライセンス契約は JDK1.2 のライブラリを ElectricalFire に用いることを許すかもしれません。将来の変更を考えておきます。
ElectricalFire は JDK 1.1 と 1.2 のどちらをサポートしますか?
現実にはまだどちらもサポートしていません。"ElectricalFire の現状は ?" をご覧ください。
ElectricalFire はどのプログラミング言語を使用していますか ?
ElectricalFire のコードのほとんどは C++ で書かれています。わずかな部分がプラットホーム依存のアセンブリコードで書かれています。
ElectricalFire はインタプリタとコンパイラの両方を含みますか ?
ElectricalFire は Java バイトコードインタプリタを含みません。全て Java バイトコードは実行の前にコンパイルされます。だから、バイトコードのがコンパイルされたかインタプリタ実行されたかの区別に依存する Java プログラムの動作の違いからくるバグが入る隙がありません。滅多に実行されないメソッド、static な初期関数のような、をコンパイルするときの遅延を減らすためにインタプリタを加えることは望ましいことかもしれません。
ElectricalFire を使うと Java コードはどのくらいの速さで動きますか ?
現実には、私たちはまだ知りません。ElectricalFire の上では大きな Java プログラムは何一つベンチマークを測定されていません。私たちは EF が少なくとも既存の JIT とほぼ同等に速いことを当然ながら期待します。プロジェクトの最終目標は、C/C++ とほぼ同等の性能を持つコードを生成することです。
私はプログラマ、だけどコンパイラは書かない。私に手伝えるか ?
はい! ElectricalFire が成功するには、私たちは構造と機能について強力なテストが必要になるでしょう。
あなたの時間を提供するのによい別の場所は Classpath プロジェクト、そこでは標準 Java ライブラリにたいする LGPL に基づいた代替を作る人を求めています。Java クラスライブラリがないと、ElectricalFire はほとんど意味をなしません。
私の Javaプログラムを動かすためには ElectricalFire をどう使えばいいのか ?
ElectricalFire を動かすのはエンドユーザにとって少し早すぎることです。一つには、Java クラスライブラリはとても限られた実装しかありません。AWT を使っている Java プログラムと一緒に使うことはできません。もちろん、EF はまだやや未完成で、多くの既知のバグがあります。最後に、デバッグサポートがありません。
ElectricalFire が Netscape の商業製品として出荷されるのはいつですか ?
ElectricalFire を商業製品として作る計画はありません、Netscape にしても私たちが知る別の誰かにしても。ElectricalFire に携わるために Netscape に雇われている人はいません。
Netscape が ElectricalFire に携わる人を雇っていないなら、誰が開発を続けようとしているのですか ?
あなたです; これはオープンソースのプロジェクトで、それが全てです。元々の開発チームにいた四人はコンパイラのアーキテクト Waldemar Horwat も含めて、開発者かつモジュール管理者としてあるいはどちらとしてボランティアを続けています。ですから現にすばらしいチームの種を持っていますが、プロジェクトが成功するためにはよりたくさんの人を必要とします。もしあなたが提供に興味があるなら、開発計画を確認してください。
ElectricalFire は Netscape のブラウザにおける公式あるいはデフォルトの JVM になるのでしょうか ?
Netscapeの OJI プロジェクトはいかなる JVM にもブラウザの内部での動作を許すことを意図しています。 Netscape による Mozilla ブラウザの商業版はおそらくデフォルトの JVM とともに配布されうるでしょう。しかし ElectricalFire にその噂はありません、商業製品として出荷される計画がないからです。オープンソースのブラウザにデフォルトの JVM は無く、また ElectricalFire をその地位に指名することもありません。
ElectricalFire の発端は何ですか ?
ElectricalFire はネットスケープ内の商業コンパイラプロジェクトとして 1997 年初頭に始まりました。このコンパイラは公に外部に宣言されることはありませんでしたが、1998 年 6 月に出荷されるようスケジュールがとられました。これが会社が Java から遠ざかる劇的な配置転換を行った 1998 年 1 月にキャンセルされました。ソースがボランティアを行う人の努力により mozilla.org で公に使える要になったのが 1999 年 1 月でした。プロジェクトのより詳しい歴史はここをクリックしてください。
このプロジェクトはその名前をどのようにもらったんですか ?
Scott Silver -最初の EF 開発メンバーの一人- がプロジェクトにそもそもつけたかったコードネームは "Sexual Chocolate"。(私がでっち上げたのではありません) この名前は拒絶されました、たぶん Netscape の管理者を困惑させたからでしょう「だって、この Sexual Chocolate プロジェクトは実際にはチョコレートに関わることを何もしていないじゃないか ?」代わりに、 Silver が提案したのは "Electrical Fire" (二つの分かれた単語) オープンソースでのリリースに当たって、 Scott Furman は二つの単語を一つにまとめ "Electrical Fire"、このプロジェクトが危険に見舞われていないことを明確にしました。知恵ある助言を一つ: あなたがこのプロジェクトで Scott Silver と共に働くことになるなら、彼にこのプロジェクトコードネームをいじらせては ならない。
どの条件の下でソースコードはライセンスされますか ?
ElectricalFire はNetscape Public Licenseの下でライセンスされます。詳細は NPL のFAQ を確かめてください。
このドキュメントのオリジナルはmozilla.orgにおいて英語で公布されています。
またドキュメントの管理の言語は現在も英語です。この日本語訳は、
利用者の利便のためにmozilla.org
和訳プロジェクトによって提供されたものです。
フィードバックは英語で、元の著者に送って下さい。
翻訳された文書の一覧は、現在以下のURLで見ることが出来ます。
http://www.mozilla-japan.org/jp/td/index.html