クラスローダがあればJITコンパイラを自前で実装できるのよねえ
iアプリの場合、一番ネックだったのがやはり「実行速度」です。
最適化には非常に悩まされました。
iアプリはJ2MEがベースとなったDoJaプロファイルという規格なんです。
J2MEは、「Java 2 Micro Edition」の略です。
Micro Editionの名の通り、PCの世界で一般的に使われる普通のJavaである「J2SE」より
機能が縮小されています。
APIが大幅に少なくなっているというのも、目立つ違いですが
Java自体の根本的な部分にも違いがあります。
- リフレクションが使えない
- JNIが使えない
- ウィーク参照が使えない
- ファイナライザが無い
- クラスローダが無い
注目なのが、クラスローダが無いということです。
クラスローダの使い道は、ファイルやネットワークから、クラスを読み込むことに留まりません。
クラスを外部から読めるということが意味するのは、「クラスを自前で作れる」ということです。
つまり、実行時に動的にクラスを作り出して、クラスローダに読み込ませることも可能です。
JavaコードがJavaのコードを紡ぎ出す格好になります。
クラスローダの使い方を応用すれば、自前でJavaでJITコンパイラを実装することが可能、ということです。
（PC上でそれをやったとすれば、自前JITコンパイラがJava bytecodeを生成し、それをHotspot VMのJITコンパイラが
ホストマシンのマシン語へ変換しながら実行する、という、JITを2段階でやるという仕組みになります）
純粋なエミュレーションより、JITコンパイラの方が高速化の可能性があるのは明らかです。
エミュレータの世界では、ダイナミックリコンパイラという名前でも呼ばれますね。
JITコンパイラも、ダイナミックリコンパイラも、同じものを指すと思っているんですが、よくわかんないです。
まあ、JITができると、大幅に高速化できる可能性が見えてきます。
しかし、J2MEにはクラスローダがありません。
これが超痛い。
かなり残念で仕方ありません。
FCCは、6502のコードを解析して、静的にJavaコードへ変換しています。
実は、静的に変換するというのは、けっこう難しいんです。
でも、静的にやらざる得なかったんですね。
クラスローダが無い以上、実行時に動的にクラスを作ることは不可能なので。
実行前にクラスを作っておくほかないわけです。
しかし、何事もやってみないとわからないことがあるんです。
コードも実行してみないと分からないことって多いんです。
静的にやるのは、何かと限界があります。
しかし、iアプリだと、どうしてもJITコンパイラを実装することが不可能なんです。
ところが、Androidにはクラスローダがあるじゃあないですか！
これがあるだけで一気に可能性が広がります。
Androidはクラスローダがあるのかぁ、と想像するだけで、ご飯３杯は食えます！
次はAndroidに手を出そうかなあ…
Windows Mobileも面白そうですけど…
