Kompatibilitas Java 32-bit vs 64-bit

97

Akankah kode Java dibangun dan dikompilasi terhadap JDK 32-bit menjadi kode byte 32-bit berfungsi dalam JVM 64-bit? Atau apakah JVM 64-bit memerlukan kode byte 64-bit?

Untuk memberikan sedikit lebih banyak detail, saya memiliki kode yang bekerja di lingkungan Solaris yang menjalankan JVM 32-bit, tetapi sekarang saya mendapatkan masalah setelah memutakhirkan JDK dan Weblogic Server ke 64-bit.

java  jvm  64-bit  compatibility  32-bit 
— mshafrir.dll
sumber
3
tolong klarifikasi "masalah".
— Thorbjørn Ravn Andersen
Saya mengalami masalah serupa - menerapkan aplikasi pegas di server weblogic 64 bit. Kami mendapatkan berbagai kelas tidak ditemukan pengecualian, dan kesalahan tidak membantu lainnya. Selain itu, ia menyebarkan dan berjalan pada beberapa mesin 64 bit, tetapi tidak pada yang lain. Namun kami tidak bisa membedakan apa yang berbeda. Apakah Anda menyelesaikan ini?
— Nont
2
@ nont - apapun masalahnya, ini bukan kompilasi 32vs64 bit.
— Stephen C

Jawaban:

94

Ya, bytecode Java (dan kode sumber) adalah platform independen, dengan asumsi Anda menggunakan pustaka independen platform. 32 vs. 64 bit seharusnya tidak menjadi masalah.

— Zifre
sumber
Saya mengalami ini saat mencari pertanyaan yang saya miliki. JADI saya menjalankan aplikasi saya di bawah JVM 32 bit dan menggunakan perpustakaan asli 64 bit. Ini berjalan dengan baik. Tetapi ketika saya menjalankan aplikasi saya di bawah 64 bit JVM dan menggunakan pustaka asli 32 bit, itu gagal. Bagaimana mungkin ini bisa terjadi? Hanya penasaran.
— Umang Desai
6
Pustaka asli @umangdesai bukanlah pustaka independen platform, oleh karena itu asumsi tidak berlaku.
— Thorbjørn Ravn Andersen
Apakah "seharusnya tidak masalah" berarti bahwa kode yang dikompilasi dengan 32-bit javacakan memanfaatkan memori yang tersedia dengan 64-bit java?
— Marcus Junius Brutus
1
Jika Anda tersengat ini, hati-hati terhadap perpustakaan asli yang telah dibundel ke dalam toples yang berfungsi untuk satu platform, tetapi tidak untuk yang memberi Anda masalah. (Jika Anda tidak tahu apa yang saya maksud, lihat hal-hal seperti ini: stackoverflow.com/a/14051512/155631 ).
— Matt S.
21

Saya tidak sengaja menjalankan aplikasi (berukuran besar) kami pada VM 64bit daripada VM 32bit dan tidak menyadarinya sampai beberapa pustaka eksternal (disebut oleh JNI) mulai gagal.

Data yang diserialkan pada platform 32bit dibaca di platform 64bit tanpa masalah sama sekali.

Masalah apa yang Anda hadapi? Apakah beberapa hal berhasil dan tidak yang lainnya? Sudahkah Anda mencoba memasang JConsole dll dan mencapai puncaknya?

Jika Anda memiliki VM yang sangat besar, Anda mungkin menemukan bahwa masalah GC dalam 64 bit dapat memengaruhi Anda.

— Fortyrunner
sumber
1
apakah Anda mengatakan bahwa perpustakaan JNI tidak akan berfungsi di VM 64 bit jika mereka 32 bit?
— C. Ross
1
Mereka tidak bekerja. Seorang kolega telah melaporkan bahwa mereka melakukannya (yang menurut saya mencurigakan - untuk sedikitnya). Saya bertanya-tanya apakah dia menggunakan Solaris dan ada semacam perdebatan yang terjadi. Tidak ada; dia salah dan itu berjalan di bawah 32bit.
— Fortyrunner
Saya mengalami masalah serupa dengan perpustakaan JNI. Tidak ada kompatibilitas antara pustaka 32-bit dan 64-bit.
— Erick Robertson
Memang, JNI libs Anda perlu diganti. Anda mungkin dapat mengunduh alternatif 64bit dari situs web vendor. (Itu berhasil bagi saya, untuk semua lib JNI yang saya gunakan).
— bvdb
Ini adalah perpustakaan internal dan tidak ada 64 bit yang setara tersedia, jadi kembali ke 32 bit adalah urutan hari ini ..
— Fortyrunner
11

Ya untuk pertanyaan pertama dan tidak untuk pertanyaan kedua; itu mesin virtual. Masalah Anda mungkin terkait dengan perubahan yang tidak ditentukan dalam implementasi pustaka antar versi. Meskipun bisa dikatakan, kondisi balapan.

Ada beberapa rintangan yang harus dilalui VM. Terutama referensi diperlakukan dalam file kelas seolah-olah mereka mengambil ruang yang sama seperti ints di tumpukan. doubledan longmenggunakan dua slot referensi. Misalnya bidang, ada beberapa pengaturan ulang yang biasanya dilakukan VM. Ini semua dilakukan (secara relatif) secara transparan.

Juga beberapa JVM 64-bit menggunakan "oops terkompresi". Karena data diselaraskan dengan sekitar setiap 8 atau 16 byte, tiga atau empat bit alamat tidak berguna (meskipun bit "tanda" mungkin dicuri untuk beberapa algoritme). Hal ini memungkinkan data alamat 32-bit (oleh karena itu menggunakan setengah bandwidth, dan karena itu lebih cepat) untuk menggunakan ukuran heap 35- atau 36-bit pada platform 64-bit.

— Tom Hawtin - tackline
sumber
3
Anda mengejutkan saya. Saya tidak berpikir ada yang namanya kode byte 32-bit atau kode 64-bit.
— Jon Skeet
3
Membaca ulang jawaban Anda - apakah Anda yakin tidak bermaksud sebaliknya? (Ya maka tidak.)
— Jon Skeet
+1 untuk Jon Skeet. Saya menulis komentar yang sama tetapi dipanggil pergi.
— Michael Myers
Maksud saya tidak, maka ya, tetapi dengan pertanyaan sebaliknya. Telah mengembalikan hasil edit dan edit (dan masukkan lebih banyak informasi).
— Tom Hawtin - tackline
4
@ Jon Skeet: tidak ada bytecode 32-bit dan 64-bit, tetapi ketika JIT, pointer-pointer di JVM (biasanya) 32 atau 64 bit, tergantung pada platformnya. Dan dengan OOPS Terkompresi, mereka dapat menggunakan pointer 32bit di banyak tempat, bahkan pada JVM 64bit. Itu menghemat cukup banyak memori dan meningkatkan lokalitas kode, sehingga mengarah ke kecepatan yang lebih tinggi.
— Joachim Sauer
9

Semua kode byte berbasis 8-bit. (Itulah mengapa disebut kode BYTE) Semua instruksi adalah kelipatan ukuran 8-bit. Kami mengembangkan pada mesin 32-bit dan menjalankan server kami dengan JVM 64-bit.

Bisakah Anda memberikan beberapa detail dari masalah yang Anda hadapi? Maka kami mungkin memiliki kesempatan untuk membantu Anda. Jika tidak, kami hanya akan menebak-nebak masalah apa yang Anda alami.

— Peter Lawrey
sumber
8

Kecuali Anda memiliki kode asli (kode mesin yang dikompilasi untuk arcitechture tertentu) kode Anda akan berjalan sama baiknya dalam JVM 32-bit dan 64-bit.

Namun, perhatikan bahwa karena alamat yang lebih besar (32-bit adalah 4 byte, 64-bit adalah 8 byte), JVM 64-bit akan membutuhkan lebih banyak memori daripada JVM 32-bit untuk tugas yang sama.

— Thorbjørn Ravn Andersen
sumber
Perhatikan juga bahwa JVM 32-bit pada sistem 64-bit mungkin memiliki lebih banyak memori yang tersedia daripada JVM 32-bit pada sistem 32-bit, jadi ini mungkin merupakan opsi yang menarik jika Anda memiliki "menggunakan beberapa GB memori "aplikasi.
— Thorbjørn Ravn Andersen
3

Perbedaan 32-bit vs 64-bit menjadi lebih penting saat Anda berinteraksi dengan pustaka asli. 64-bit Java tidak akan dapat terhubung dengan 32-bit non-Java dll (melalui JNI)

— John Thomas
sumber
5
Anda tidak memberikan sesuatu yang baru untuk pertanyaan yang sangat lama ini.
— Austin Henley
0

Java JNI membutuhkan pustaka OS dengan "bittiness" yang sama seperti JVM. Jika Anda mencoba membuat sesuatu yang bergantung, misalnya, pada IESHIMS.DLL (ada di% ProgramFiles% \ Internet Explorer), Anda perlu mengambil versi 32-bit saat JVM Anda 32-bit, versi 64-bit ketika JVM Anda 64-bit. Begitu juga untuk platform lainnya.

Selain itu, Anda harus siap. Bytecode Java yang dihasilkan s / b sama.

Perhatikan bahwa Anda harus menggunakan compiler 64bit Java untuk proyek yang lebih besar karena dapat menangani lebih banyak memori.

— thecarpy
sumber
-5

yo dimana salah! Untuk tema ini saya menulis pertanyaan kepada oracle. Jawabannya adalah.

"Jika Anda mengkompilasi kode Anda pada Mesin 32 Bit, kode Anda seharusnya hanya berjalan pada Prosesor 32 Bit. Jika Anda ingin menjalankan kode Anda pada 64 Bit JVM Anda harus mengkompilasi file kelas Anda pada Mesin 64 Bit menggunakan 64 Bit. -Bit JDK. "

— elayer
sumber
5
The Format kode byte kode Java biasanya disusun untuk adalah sama terlepas dari 32bit atau 64bit platform. Aturannya berbeda untuk kode asli apa pun, tetapi kode byte Java bersifat portabel.
— McDowell
4
Ya, sepertinya siapa pun di Oracle yang menjawab pertanyaan Anda salah paham atau tidak tahu apa-apa tentang JVM.
— Paŭlo Ebermann
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.