JarBundler を使用してパッケージ化された Java アプリがあります。アプリはかなり CPU を集中的に使用します (多数の大きな Collection.sort() 呼び出し)。
Mac OS では、64 ビットの JavaApplicationStub を使用すると、アプリの動作が遅くなります。この JavaApplicationStub ファイルは、Java 64 ビット VM を起動しています。
32 ビットのみの古い JavaApplicationStub ファイルを見つけました。バンドルでそれを置き換えたところ、アプリの実行速度が 10 倍になりました! (したがって、アプリケーションの実行時には 32 ビット VM が使用されます)。
これは意味がありますか？64 ビット VM が非常に遅いのはなぜですか? アプリをビルドして JavaApplicationStub ファイルをこのようにハックするのは理にかなっていますか?
アドバイスをいただければ幸いです。
64ビットJVMを実行することのメリット/デメリットについては、この投稿を参照してください。要約すると、ポインタの逆参照とメモリの割り当て解除には時間がかかる可能性があります。また、より大きなデータ構造（つまり、32ビットではなく64ビット）を移動しているため、明示的に使用しない限り、利点はありません。
この関連記事も参照してください。64ビットに移行すると、パフォーマンスが最大85％低下することが説明されています。これは、現在の状況と一致しています。
このパフォーマンスの低下の理由は、実際にはメモリの増加に大きく関係しています。Javaの内部でのメモリ参照は、2倍のサイズになり、WASランタイムとアプリケーションのオブジェクトのメモリ構造のサイズが増加しました。残念ながら、プロセッサのメモリキャッシュサイズは同時に大きくなりませんでした。これは、より多くのメモリキャッシュミスを意味します。これは、より大きなメモリを処理するハードウェアのより多くのビジー作業を意味し、アプリケーションのパフォーマンスを低下させることを意味します。