移植に関する一般的な考慮事項

64 ビット・プロセッサー上の Java プラットフォーム

Java API およびネイティブ・コードの移植

前の図は、重要なコンポーネントを識別し、アプリケーションを 32 ビット から 64 ビットに移植する際に何を変更する必要があるかを理解するのに役立ちます。 すべての Java アプリケーションは、定義済みの Java アプリケーション・プログラミング・インターフェース (API) に書き込まれます。 この API は、Java プラットフォームの 32 ビット ・バージョンと 64 ビット・バージョンで同じです。

Java API には、Java プラットフォームの基本部分である Java クラス・ライブラリー (例えば、 awt、 swing、 net、 lang、 io、および rmi) が含まれています。 Java API およびすべての Java コードは、64 ビット実装では、 32 ビット 実装の場合とまったく同じです。 したがって、 32 ビット Java システムで実行される Java アプリケーション・コードは、64 ビット・システムでは変更されずに実行されます。

多くの Java アプリケーションは、Java 言語では 100% 作成されていません。 これらのアプリケーションでは、それらのコードの一部は、一般に「ネイティブ・コード」と呼ばれる C や C++ などの非 Java 言語で作成されています。 ネイティブ・コードを持つ Java アプリケーションの移植には、より多くの労力がかかります。

すべての Java コード (アプリケーションおよびクラス・ライブラリー) は、Java 仮想マシン (Java VM) によって実行されます。 Java VM には、Java コードを実行し、Java ヒープ内のデータを管理するサブコンポーネントが含まれています。 J9 VM には、実行前に Java コードをネイティブ・プロセッサー命令にコンパイルするジャストインタイム・コンパイラー (JIT) が組み込まれています。 このコンパイル処理により、コードのパフォーマンスが最大限に引き出されます。

Java 環境の 64 ビット実装では、64 ビット・プログラムとして実装され、基礎となるプロセッサーの 64 ビットの性質を認識するのは、Java VM です。 これには、64 ビット・アドレスを使用するために Java コードをコンパイルする必要がある JIT コンパイラーが含まれます。 この JIT コンパイラーも、基礎となるプロセッサーで使用できる完全な 64 ビット命令セットを認識します。

Java VM は、ホスト・ポート・インターフェース (HPI) を介してオペレーティング・システムと通信します。 この通信により、Java VM コードは基礎となるオペレーティング・システムから独立し、Java プラットフォームの IBM 実装が特定のプロセッサー・タイプでさまざまなオペレーティング・システムをサポートできるようになります。

JNI およびネイティブ・コード

Java VM、HPI 層、および Java コードはすべて、単一の 64 ビット・オペレーティング・システム・プロセス内で実行されます。 通常は、一部のネイティブ・コードがそれと同じプロセス内で実行されます。 そのようなネイティブ・コードは、直接対象のプロセッサーとオペレーティング・システム用にコンパイルされた 1 つ以上のコード・ライブラリーです。 ネイティブ・コードは、Java ネイティブ・インターフェース (JNI) を介して Java コードからアクセスされます。 ネイティブ・コードは、JNI を介して Java オブジェクトおよびメソッドにアクセスすることもできます。 一部のネイティブ・コードは、オペレーティング・システムによって提供される Java グラフィックスおよびウィンドウ操作を使用する awt クラス 関数を実装するコードなど、 J2SE 実装の一部です。 また、アプリケーションの一部として提供されるネイティブ・コードが存在することもあります。

JNI に類似したインターフェースとして、Java 仮想マシン・ツール・インターフェース (JVMTI) が他に 1 つあります。 このインターフェースは、Java アプリケーションのプロファイル作成とデバッグのための機能を提供します。 この機能を使用するには、多少のネイティブ・コードをコーディングする必要があります。

Java プラットフォームの 64 ビット実装の場合、64 ビット Java VM に関連付けられているすべてのネイティブ・コードは 64 ビットでなければなりません。これは、すべて Java VM と同じプロセス・スペースで実行されるためです。 同じプロセス・スペース内で 64 ビット・コードと 32 ビット ・コードを実行することはできません。これら 2 つのタイプのコード間でアドレス・サイズに互換性がないためです。

ネイティブ・コード (通常は、C 言語または C++ 言語でコーディングされる) はこのアドレス・サイズを直接認識します。 アプリケーションに含まれるネイティブ・コードは、64 ビット環境における差異 (64 ビット・アドレスなど) を正しく処理できるように変更する必要があります。 最終的に、ネイティブ・コードも 64 ビット・システム用に再コンパイルおよび再リンクする必要があります。

要約すると、64 ビット Java VM 実装は 64 ビット・プロセッサー上で実行され、同様に 64 ビット「認識」のコードにリンクします。 Java VM は、基礎となるプロセッサーのラージ・メモリー・サポートおよび 64 ビット命令を使用することもできます。 実行される Java アプリケーションは、Java の 32 ビット 実装環境で実行できるものとまったく同じです。 32 ビット ・システムから 64 ビット・システムに移植する必要があるのは、ネイティブ・コードのみです。

32 ビット から 64 ビットに移行する場合の Java プログラムの利点

Java 言語および環境は、 32 ビット ・コンピューティングから 64 ビット・コンピューティングへの直接的な移行を行います。 C や C++ など、明示的なアドレス・ポインターを持つ他の言語で作成されたプログラムの場合、アプリケーションを 32 ビット から 64 ビットに移植するには、かなりの労力がかかることがあります。 これは、アプリケーションが 64 ビット環境で正しく実行されるように、各ポインターを 64 ビットの数量として宣言し直し、アドレスに関する計算を慎重に調べて調整する必要があるためです。 対照的に、100％のJavaアプリケーションは、64ビット環境で正しく実行するために再コンパイルする必要さえない。 Java アプリケーションの場合、すべてのハード作業は Java VM 実装によって行われますが、基礎となるポインター・サイズはビューに表示されません。