携帯Javaのことで質問です。


最近の携帯電話のJava仮想マシンでは、JITコンパイルを行っているのでしょうか?
ネットで調べたところ、最近の携帯ではJBlendが多く採用されていることが分かったのですが、
開発元のページを見ても、JITを行っているか、行っていないかは良く分かりませんでした。
しかし、「FTT」等という高速化技術がJBlendで使われていることが分かりました。しかし、詳細は分かりませんでした。

携帯Javaで実際に使われている高速化技術と、その内容について教えてください。お願いします。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2008/10/01 21:41:51
  • 終了:2008/10/08 21:45:03

回答(2件)

id:angemaries No.1

angemaries回答回数80ベストアンサー獲得回数22008/10/02 01:47:25

ポイント35pt

JBlend限定の話です。

・JITではありません。

・FTTはオーバヘッドの大きかったスレッド処理をOS側とあわせるなどの処置をして高速化するものです。

http://www.aplix.co.jp/jp/release/2000/pr000515.html

id:aoisome

回答ありがとうございます。

JITでは無いんですね…

早くJITが乗るようになってほしいです。

ずいぶん前の記事(下のリンク)ですが、CLDC Hotspotにも対応していくということが書いてあるのですが、進んでないんですねえ…

http://plusd.itmedia.co.jp/mobile/0208/27/n_jblend.html

2008/10/02 19:20:56
id:pascal7 No.2

pascal7回答回数582ベストアンサー獲得回数982008/10/02 21:13:34

ポイント35pt

JITコンパイルはいらない技術だと思いますが?

例えばARM CPUだと

Jazelleと言って中間コードを直接実行する機構を備えています。

直接機械語として実行できるのにコンパイルする必要は無いのでは?


>ARMは、Javaバイトコードをハードウェアでネイティブに実行できる技術を実装した。

>これはARMやThumbモードと並ぶもう一つの実行モードであり、ARM/Thumbの切り替えと

>同様にしてアクセスすることができる。

>Jazelleテクノロジを搭載した最初のプロセッサはARM926EJ-Sである。CPU名の'J'がJazelleを表している。

http://ja.wikipedia.org/wiki/ARM%E3%82%A2%E3%83%BC%E3%82%AD%E3%8...

どうでしょうか?

id:aoisome

Jazelleという技術があるのですね。ありがとうございます。

しかし、そうだとしてもJITもあれば良いなと私は思うのですが…

以下2つの理由があります。

1.Javacの出力するバイトコードは、JITコンパイルを前提としている為、ほとんど最適化らしい最適化がされていないこと

2.Java bytecodeをハードウェアでネイティブに実行できても、Java bytecodeをはスタックマシン・アーキテクチャなので、本来のARMネイティブコードほどの速度はたぶん出ないと思われること


調べてみたのですが、JITコンパイルがまったく必要無いとは言い切れないと思われます。

http://www.jp.arm.com/products/multimedia/jazelletechnology/jaze...

>ARM Jazelle RCT(Runtime Compilation Target)テクノロジーは、Javaその他の実行環境で、

>効率的な事前(AOT)コンパイル、ジャストインタイム(JIT)コンパイルを実現します。

>また、Jazelle RCTは、起動時間や動作の滑らかさがさほど問題にならない超高速プラットフォームで

>AOTコンパイルの使用量を増やす際に使用され、JIT技術と併用されることもあります。

携帯電話のハードウェア資源が潤沢になれば、JIT等も併用されうるのではないでしょうか。

2008/10/02 22:53:07
  • id:pascal7
    もう少し携帯電話のresourceが豊かになったら意味があるようになるかもと言う事ですか…
    もし、そうならフルコンパイルして機械語にしてしまうなり
    C++で書く方が高速に処理が出来ると言う事になるのではと思います。

    またすでに海外ではJavaでなくバイナリでプログラムを書く(C++)時代だと思います。
    日本は、各社のハードウエアが異なると言う状況の問題を解消するためにJavaが使われていると思います。

    JITコンパイルが有益な時期と言うのはある程度短い時間しか発生しないのではないでしょうか?
    もし、オプティマイズなり(高速性などの意味で)が重要であればC++を使うか(Javaを使うにしても)
    フルコンパイルすると良いのでは無いでしょうか?
  • id:aoisome
    C++で組むという選択肢が使えるならば良いのですが、Docomoの携帯向けのアプリを作ろうと思えば、Javaで組む以外の選択肢が無いのが現実かと思います。

    JITコンパイルは、短い時期しか有益では無いとの意見ですが、将来的にどういう実行方式が有利とされ、主流になっているかは、私には分かりません。
    しかし、現状の携帯Javaの場合、JITが無いので不便なのです。
    以下のような場合を考えてみてください。

    例えばですが、
    public class Test {
    public static void main(String[] args) {
    int tmp1 = 100;
    int tmp2 = tmp1;
    System.out.println(tmp2);
    }
    }
    と書いた場合、バイトコードで8命令にコンパイルされました。

    以下は一時変数に代入しない場合のコードです。
    public class Test {
    public static void main(String[] args) {
    System.out.println(100);
    }
    }
    これは、バイトコードで4命令にコンパイルされます。

    メジャーなJavaコンパイラはだいたい試したのですが、上のような場合に有効と思われる、定数伝播の最適化すら行わないという思想のようです。
    そして、携帯のVMにはJITがありません。
    結果的に、最適化が、どのフェーズでも行われないまま、コードがそのまま実行されている、というのが携帯Javaの現状の様です。

    速度やサイズを意識したコードを組もうと思えば、上の例のように、重箱の隅をつつくようなことまで気を使わないといけない状況です。計算途中の値を、変数に代入しただけで、コードサイズが増えていくのですから、困ったものです。
    式を1行に押し込んだ方が高速になるので、突き詰めれば、可読性を捨ててそういう書き方をしないといけないかもしれません。コンパイラかJITの最適化が期待できれば、そういう細かいことは気にせずに、可読性を意識したコードを組めるはずなのですが。
  • id:pascal7
    ドコモの仕事をする場合Javaを使うしか選択肢が無いと思います。

    でも、aoisomeさんがiPhoneの仕事をするとしたらまずC++でコーディングする事を考慮されるのでは?
    Windows携帯の仕事をする時もC++で開発することを検討去れませんか?
    AUの仕事をするとしてもBREW(C++)でコーディングする事を考えられるでしょう?
    海外の携帯の仕事をする時もC++でコーディングする事を考慮されるのではないですか?

    ドコモやソフトバンクの場合携帯のハード、ファームの違いがあるので
    Javaと言う皮を被せて違いを吸収する必要があるのだと思います。

    でも、ドコモも何時かはハード、フォームを統一して機械語でアプリを書いてもらう
    環境を整えるのではないでしょうか?

    今は携帯のソフトと言うとJavaで書いたドコモ用のソフトだねと言うのが正しいと思いますが
    iPhoneは業務ソフトに対応するそうじゃないですか。
    >Salesforce Mobile for iPhone 3G
    >IBM Lotus iNotes
    >Oracle Business Indicators
    >CACHATTO for iPhone 3G
    http://plusd.itmedia.co.jp/mobile/articles/0810/10/news029.html

    ドコモがJavaとサーバーサイドの対応だけで戦えるかと言うと戦えないのでは…

    サンプル問題をC++で書くと(ARM CPUの場合)
    変数に入れても即値でも2命令の機械語になると思います。
    システムを呼び出す時はスタックフレームを作成するかも知れませんが
    関数コールでと言う問題だと思いますので
    ARM手続き呼び出し規格の為4つまでのパラメータはレジスタ渡しになります。
    >mov r0,#100
    >bl println
    こんな感じかなと思います。
    this pointerもレジスタで渡されると思います。
    十進100は幸い8ビットの即値として格納されると思います。
    32ビットコードなら8バイト、16ビット(Thumb)コードなら4バイトだと思います。

    変数に一端格納するかと言うのは
    オプティマイザーが働くので
    コードの差がでないと思います。

    Javaの人から見るとC++は許しがたい汚い言語だと思いますが
    速さで言うと明らかにC++の方が速いでしょう?
    今は携帯のアプリと言うとJavaですが
    将来機械語のアプリの時代が来るのでは無いでしょうか?
    機械語のと言っているだけなので
    Javaフルコンパイラでも、C++コンパイラでも良いだろうと思いますが。
    どうでしょうか?
  • id:aoisome
    iPhoneの開発はObjective Cだと思います。
    Windows Mobileの携帯なら、.NETを使うと思います。
    .NETは、C++より生産性が段違いに高いです。
    でも本当は、私はJavaよりC++の方が好きですよ。
    C++で当たり前の最適化が、Javaでは行われていないらしいことを疑問に思って質問しました。

    個人的には、携帯などのモバイル分野でC++が復権することは無いと思っています。
    googleのAndroidでも、Javaがメインになるみたいですので。
    各キャリアの端末で、最大公約数的に使える言語は、Javaなのではないでしょうか。
    私は個人的に携帯アプリの開発をやっていますが、BREWは間口が狭すぎて難しいものがあります。
    使えるならばC++を使いたいのですが、C++は必要以上に何でも出来てしまいます。C++を使った場合、キャリアの審査が通らないと実機で検証すら出来ないという状況は、今後も変わらないのではないでしょうか。

    JavaなどのVM上で動作する言語は、制約も大きいですが、そのかわり間口が開かれているというのはとても魅力的に映ります。制約は、うまく工夫して乗り越えるしか無さそうですね。
    色々なご意見を頂いて、参考になりました。ありがとうございました。
  • id:pascal7
    将来どうなるかと言うのは断言できません。
    私は機械語で各時代になると思っていますが。

    >各キャリアの端末で、最大公約数的に使える言語は、Javaなのではないでしょうか。
    それはその通りだと思います。
    Javaで書いてあれば
    AU携帯でもオープンアプリと言う形で乗せられると思います。

    >C++は必要以上に何でも出来てしまいます。C++を使った場合、
    >キャリアの審査が通らないと実機で検証すら出来ないという状況は、今後も変わらないのではないでしょうか。
    そうかも知れません。
    でも、フリーソフトを作る人は困ると思いますが。
    携帯用のアプリを作る人は問題にならないと思います。
    ただ、上司に認証の手続きを行う費用をかけても儲かるのかと言われると思いますが。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません