7

Javaを抽象マシンまたは仮想マシンとして実装することの真の利点、つまり言語を抽象マシン用の言語にコンパイルすることの利点を理解しようとしています。プラットフォームの独立性に関する限り、次の 2 つの代替実装を考えていました。

  • Javaを実行中のマシンのマシンコードに直接変換するインタープリターがあり、さまざまなタイプのマシン用にそのようなインタープリターの複数の実装があるだけです。

  • 最初のオプションは空間的に効率的ではないため、ソースコードを中間言語にコンパイルするのはどうですか。これは抽象的な機械の言語ではなく、機械コードに解釈できる言語であり、そのようなインタープリターの複数の実装を持っています。

パフォーマンスが考慮されていない場合、抽象的なマシンを持つことはこれらのオプションとどのように比較されますか. 言い換えれば、Java バイト コードが仮想マシン用の言語ではなく、単なる中間言語であるとしたらどうなるでしょうか。どのような機能と利点が失われるでしょうか (パフォーマンスを除く)?

4

4 に答える 4

5

バイトコードは単なる中間言語です。

またはその逆：中間言語の実装は仮想マシンです。

于 2012-05-09T07:13:51.803 に答える
2

あなたが説明することは、本質的にJavaとJVMが現在行っていることです。Java はbytecodeと呼ばれるものにコンパイルされます。これは中間言語です (スタック ベースのマシンのアセンブリに非常によく似ています)。次に、JVM はこのコードを解釈し、ジャスト イン タイム (JIT) コンパイルと呼ばれるプロセスで、その一部をオンザフライでマシン コードに変換します。JVM は、移植性を支援する他の処理 (同時実行の管理やメモリ構造/管理など) を行います。

于 2012-05-09T07:06:08.757 に答える
2

Java が実行時にマシン コードに直接変換された場合、コンパイラが提供するタイプ セーフ機能が失われます。コンパイラがエラーを報告しないという事実は、特定の種類のエラーが実行時に発生しないことを保証します。コンパイラ フェーズを削除すると、実行時にこれらのエラーが表示されます。

一方、Java バイトコードは、他の言語よりも少しレベルが高いとはいえ、中間言語です。JVM は、一部を解釈して実行し、一部をマシン コードにコンパイルして実行します。

于 2012-05-09T07:02:01.623 に答える
-1

すべてのバリアントは実際に実際に使用されており、適切な妥協点を選択することがすべてです。

Java 用 - 多くのプラットフォームのディストリビューションに便利で、起動時間が遅くなります:

  • バイトコードにコンパイルされた Java ソース
  • 解釈されたバイトコードおよび/または
  • マシンコードにコンパイルされたバイトコード JIT

JavaScript の場合 - 配布に最も便利 / 高速化するには多くの作業が必要です):

  • JavaScript ソースを解析 + 解釈、または JIT コンパイルしてマシン コードに変換

for .NET - AOT は、起動時間を高速に保ちながら VM 言語のすべての利点を備えていますが、ほとんどが 1 つのターゲット システム タイプにロックされています。

  • C#/F#/VB/... IL にコンパイル (中間言語 / 別のバイトコード)
  • .NET IL コードの解釈および/または
  • マシン コードにコンパイルされた .NET IL JIT または
  • .NET IL AOT コンパイル済み (事前に) (ほとんど x86 用) および配布済みコンパイル済み

これは主に使用されているものですが、javascript をバイトコードにコンパイルしたり、java をマシンコードにプリコンパイルしたり、GWT のように Java を javascript にコンパイルしたりすることもできます。

于 2012-05-09T07:28:10.090 に答える