64 ビット コンパイラで Java プログラムを実行し、そのプログラムのバイト コードを生成しました。データを失うことなく、32 ビット コンパイラで同じバイト コードを実行することは可能ですか?
私のプログラムでは、x=10024
64 ビット コンパイラで変数を宣言しましたか?
では、32 ビット コンパイラでの x の値はどうなるでしょうか? x の値が同じ場合、どのようにしてデータを失わずに可能なのでしょうか? 詳しく教えてください。
「32ビット」コンパイラを実行する場合は、32ビットJVMでコンパイラコードを実行し、「64ビット」コンパイラを実行する場合は、64ビットJVMでまったく同じコードを実行します。まったく同じバイトコードを生成します。バイトコードが完全に同じでない場合は、バグが見つかりました。唯一の違いは、「64ビット」バージョンの実行速度がわずかに速くなる可能性があることです(推測では最大5%)。
64ビットコンパイラでJavaプログラムを実行しました
バイトコードは、実行するのではなく、コンパイラでコンパイルします。
そのプログラムのバイトコードを生成しました。
バイトコードは32ビットでも64ビットでもないため、作成方法やコンパイラを実行したJVMに違いはありません。
データを失うことなく、32ビットコンパイラで同じバイトコードを実行することは可能ですか?
32ビットか64ビットかに関係なく、同じバージョンまでの任意のバージョンのJavaでコンパイルされたクラスを使用してコードをコンパイルできます。
私のプログラムでは、64ビットコンパイラで変数x = 10024を宣言しましたか?
それは意味がありません。int x=10024;
64ビットJVMで実行されているコンパイラを使用するようにコードをコンパイルした可能性があります。それがどのようにコンパイルされたかは、何の違いもありません。
では、32ビットコンパイラのxの値はどうなるでしょうか。
32ビットJVMまたはその他のJVMで実行されているコンパイラの場合と同じです。
xの値が同じである場合、データを失うことなくどのように可能ですか?
データが失われる理由はありません。の場合x
、int
コードのコンパイル方法やコンパイラの実行に使用されたJVMに関係なく、32ビットの符号付き値になります。
JVMは、64ビットか32ビットか、リトルエンディアンかビッグエンディアンかに関係なく、アーキテクチャに関係なく、バイトコードが同等に動作することを保証します。Javaバイトコードの場合:
その後、JVMは、実行時にバイトコードをネイティブコードに最適化する場合としない場合があります(シーンを超えて必要なエンディアンマジックを実行します)。
必要に応じて、バイトコードを「Javaアセンブリ言語」と考えてください。ただし、すべてのCPUアーキテクチャにそのようなアセンブリ言語は1つしかありません。つまり、そのアセンブリ言語を「実行」することがJVMの役割です。
Javaコンパイラは、物理マシンのアーキテクチャに依存しないバイトコードを生成します。Java仮想マシンは、そのアーキテクチャがコードがコンパイルされたマシンのアーキテクチャと同じであるかどうかにかかわらず、このバイトコードを実行できます。
Java整数型は4バイトです。32、64、または128ビットマシンのいずれか。Javaのlong型は8バイトです。等
はい、プリミティブ変数のプラットフォーム値に関係なく、同じままです。floatデータ型を除いて、精度はstrictfpを指定するかどうかによって異なります。
Java言語仕様から:Strictfpは、すべてのプラットフォームで浮動小数点計算からまったく同じ結果が得られることを保証します。strictfpを使用しない場合、JVM実装は、可能な場合は追加の精度を自由に使用できます。
生成されるバイトコードはプラットフォームに依存しません。32 ビットまたは 64 ビットのマシンで同じバイトコードを実行しても、違いはありません。ほとんどのシナリオでまったく同じように動作するはずです。
ネイティブ コード (特定のアーキテクチャ用にコンパイルされたマシン コード) がない限り、コードは 32 ビットと 64 ビットの JVM で同じように動作します。つまり、プラットフォームに依存しません。
x = 10024
int 変数 x は、両方のアーキテクチャで 32 ビットの固定小数点値として表されるため、損失や予期しない動作は発生しません。
fgが正しいです。
詳細: Java は、int が BigEndian で 4 バイト、float が BigEndian で 4 バイト、long が BE で 8 バイトなどを保証します...
これは、基礎となるアーキテクチャに関係なく維持されるため、8 ビット マシンで long を使用すると、1 つの long で 8x8 ビットで動作する必要があるため、非常に遅くなります。
ただし、プラットフォームおよびアーキテクチャ固有の JVM は、可能な限り最適化を試みます。
Java は、コードを実行できる Java 仮想マシン (JVM) で実行されます。JVM は、Java バイトコードを実行できるランタイム環境を提供し、すべてのソフトウェア エラー (例外) の根本原因のデバッグ情報を提供する自動例外処理などの機能を有効にします。JVM は、Java アプリケーション プログラミング インターフェイス (API) を実装する標準クラス ライブラリのセット (Java バイトコード) である Java クラス ライブラリと共に配布されます。これらのライブラリは、JVM と一緒にバンドルされて、Java ランタイム環境 (JRE) を形成します。JVM は、多くのハードウェアおよびソフトウェア プラットフォームで利用できます。すべてのプラットフォームのすべての JVM で同じバイトコードを使用することにより、Java は、クロスプラットフォームのコンパイル済み言語を記述する「write once, run Anywhere」プログラミング言語ではなく、「write once, run Anywhere」プログラミング言語として記述することができます。したがって、JVM は Java プラットフォームの重要なコンポーネントです。JVM は、ほとんどの場合、既存のオペレーティング システム上で実行するように実装されますが、ハードウェア上で直接実行するように実装することもできます。必要に応じて独自のものを作成することができ、Java をどこにでも移植できます。ソース:ウィキペディア