Java 32ビットと64ビットの互換性


97

32ビットJDKに対してビルドおよびコンパイルされて32ビットバイトコードにコンパイルされたJavaコードは、64ビットJVMで動作しますか?または、64ビットJVMには64ビットバイトコードが必要ですか?

もう少し詳しく説明すると、32ビットのJVMを実行しているSolaris環境で動作していたコードがありますが、JDKとWeblogic Serverを64ビットにアップグレードすると問題が発生します。


3
「問題点」を明確にしてください。
するThorbjörnRavnアンデルセン

同様の問題があります-64ビットのweblogicサーバーにSpringアプリをデプロイします。クラスが見つからない例外やその他の役に立たないエラーが発生します。さらに、一部の64ビットマシンでのみ展開および実行できます。ただし、何が違うのかはわかりません。あなたはこれを解決しましたか?
2009

2
@nont-問題が何であれ、32vs64ビットのコンパイルではありません。
スティーブンC

回答:


94

はい。Javaバイトコード(およびソースコード)は、プラットフォームに依存しないライブラリを使用している場合、プラットフォームに依存しません。32ビットと64ビットは関係ありません。


私が持っていた質問を探している間に私はこれに遭遇しました。私は32ビットのJVMでアプリケーションを実行し、64ビットのネイティブライブラリを使用しました。うまくいきました。しかし、64ビットのJVMでアプリケーションを実行し、32ビットのネイティブライブラリを使用すると、失敗します。これはどのようにして可能でしょうか?ちょっと興味があるんだけど。
Umang Desai 2013年

6
@umangdesaiネイティブライブラリはプラットフォームに依存しないライブラリではないため、仮定は成り立ちません。
–ThorbjørnRavn Andersen 2013

「問題ではない」とは、32ビットでコンパイルされたコードjavacが64ビットで利用可能なメモリを利用することを意味しますjavaか?
マーカスジュニウスブルータス

1
これに悩まされている場合は、jarにバンドルされているネイティブライブラリに注意してください。1つのプラットフォームでは機能しますが、問題を引き起こすプラットフォームでは機能しません。(私が何を参照しているのか分からない場合は、次のようなものを参照してください:stackoverflow.com/a/14051512/155631)。
Matt S.

21

(大規模な)アプリケーションを32ビットVMではなく64ビットVMで誤って実行しましたが、(JNIによって呼び出される)外部ライブラリの一部が失敗するまで気付きませんでした。

32ビットプラットフォームでシリアル化されたデータは64ビットプラットフォームで読み込まれ、問題はまったくありませんでした。

どのような問題が発生していますか?機能するものとそうでないものがありますか?JConsoleなどを取り付けてみて、ピークが発生しましたか?

非常に大きなVMを使用している場合、64ビットのGCの問題が影響を与える可能性があります。


1
JNIライブラリーが32ビットの場合、64ビットVMでは機能しないと言っていますか?
C.ロス

1
彼らは動作しません。同僚がそうしたと報告していました(控えめに言っても私は疑わしいと思いました)。彼がSolarisで実行されているのか、ある種のサンクが起こっているのかと思いました。ありませんでした。彼は誤解され、32ビットで実行されていました。
Fortyrunner 2010年

JNIライブラリでも同様の問題が発生しました。32ビットと64ビットのライブラリ間に互換性はありませんでした。
エリックロバートソン

実際、JNIライブラリを置き換える必要があります。おそらく、ベンダーのWebサイトから64ビット版の代替をダウンロードできます。(それは私にとって、私が使用したすべてのJNIライブラリにとってはトリックでした)。
bvdb

これらは、内部ライブラリなし64ビット相当のでバック32ビットへ日のオーダーであり、利用可能であった..た
Fortyrunner

11

最初の質問にははい、2番目の質問にはいいえ。それは仮想マシンです。あなたの問題はおそらく、バージョン間のライブラリ実装の不特定の変更に関連しています。たとえば、競合状態である可能性もあります。

VMが通過しなければならないいくつかのフープがあります。特に、参照はint、スタック上のs と同じスペースを取るかのようにクラスファイルで処理されます。doubleそしてlong二つの基準スロットを取り上げます。インスタンスフィールドの場合、VMが通常とにかく通過するいくつかの再配置があります。これはすべて(比較的)透過的に行われます。

また、一部の64ビットJVMは「圧縮oop」を使用します。データは約8または16バイトごとに整列されるため、アドレスの3または4ビットは役に立ちません(ただし、「マーク」ビットは一部のアルゴリズムで盗まれる可能性があります)。これにより、64ビットプラットフォームで32ビットアドレスデータ(したがって、半分の帯域幅を使用するため、より高速)が35ビットまたは36ビットのヒープサイズを使用できるようになります。


3
あなたは私を驚かせます。32ビットのバイトコードや64ビットのバイトコードのようなものがあるとは思いませんでした。
ジョンスキート

3
答えをもう一度読んでください。逆に言ったのではなかったのですか?(はい、いいえ。)
ジョン・スキート

ジョン・スキートへの+1。私は同じコメントを書いていたが、呼ばれた。
マイケルマイヤーズ

私は「いいえ」を意味し、「はい」を意味しましたが、質問はその逆です。編集をロールバックして編集しました(そしてもう少し情報を入れました)。
トム・ホーティン-タックライン2009

4
@Jon Skeet:32ビットと64ビットのバイトコードはありませんが、JITを実行すると、JVMのポインターは(通常)32または64ビットであり、プラットフォームによって異なります。また、圧縮OOPSを使用すると、64ビットのJVMであっても、多くの場所で32ビットのポインターを使用できます。これにより、かなりのメモリが節約され、コードの局所性が向上するため、速度が向上します。
ヨアヒムザウアー

9

すべてのバイトコードは8ビットベースです。(それが、BYTEコードと呼ばれる理由です)すべての命令は、サイズが8ビットの倍数です。32ビットマシンで開発し、64ビットJVMでサーバーを実行しています。

直面している問題の詳細を教えてください。その後、私たちはあなたを助けるチャンスがあるかもしれません。そうでなければ、私たちはあなたが何の問題を抱えているのかを推測しているだけです。


8

ネイティブコード(特定のアーキテクチャ用にコンパイルされたマシンコード)がない限り、コードは32ビットと64ビットのJVMで同じように実行されます。

ただし、アドレスが大きいため(32ビットは4バイト、64ビットは8バイト)、64ビットJVMは同じタスクで32ビットJVMより多くのメモリを必要とします。


また、64ビットシステムの32ビットJVMは、32ビットシステムの32ビットJVMよりも多くのメモリを利用できる可能性があるため、「数GBのメモリを使用する場合、興味深いオプションになる場合があります。 " 応用。
–ThorbjørnRavn Andersen 2013

3

32ビットと64ビットの違いは、ネイティブライブラリとやり取りする場合にはさらに重要になります。64ビットJavaは、32ビットの非Java DLLと(JNIを介して)インターフェースできません。


5
あなたはこの非常に古い質問に新しいものを提供しませんでした。
オースティンヘンリー2012


0

Java JNIには、JVMと同じ「ビットネス」のOSライブラリが必要です。たとえばIESHIMS.DLL(%ProgramFiles%\ Internet Explorerにある)に依存するものをビルドしようとする場合、JVMが32ビットの場合は32ビットバージョン、JVMが64ビットの場合は64ビットバージョンを使用する必要があります。他のプラットフォームについても同様です。

それを除いて、あなたはすべて準備ができているはずです。生成されたJavaバイトコードは同じです。

より大きなメモリをアドレス指定できるため、大規模なプロジェクトには64ビットJavaコンパイラを使用する必要があることに注意してください。


-5

どこが間違っている!このテーマに私はオラクルに質問を書きました。答えはだった。

「32ビットマシンでコードをコンパイルする場合、コードは32ビットプロセッサでのみ実行する必要があります。64ビットJVMでコードを実行する場合は、64を使用して64ビットマシンでクラスファイルをコンパイルする必要があります。 -ビットJDK。」


5
バイトコード形式のJavaコードは通常にコンパイルさに関係なく、32ビットまたは64ビットのプラットフォームと同じです。ルールはどのネイティブコードでも異なりますが、Javaバイトコードは移植可能です。
McDowell、

4
ええ、Oracleの誰もがあなたの質問に誤解していたか、JVMについて何も知らなかったようです。
パウロEbermann
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.