ความเข้ากันได้ของ Java 32 บิตเทียบกับ 64 บิต


97

โค้ด Java ที่สร้างและคอมไพล์เทียบกับ JDK 32 บิตเป็นโค้ดไบต์ 32 บิตทำงานใน JVM 64 บิตหรือไม่ หรือ JVM 64 บิตต้องการรหัส 64 บิตไบต์?

เพื่อให้รายละเอียดเพิ่มเติมเล็กน้อยฉันมีโค้ดที่ทำงานในสภาพแวดล้อม Solaris ที่ใช้ JVM 32 บิต แต่ตอนนี้ฉันได้รับปัญหาหลังจากอัปเกรด JDK และ Weblogic Server เป็น 64 บิต


3
โปรดชี้แจง "ประเด็น"
Thorbjørn Ravn Andersen

ฉันมีปัญหาที่คล้ายกัน - กำลังปรับใช้แอปสปริงบนเซิร์ฟเวอร์เว็บล็อก 64 บิต เราได้รับข้อยกเว้นไม่พบคลาสต่างๆและข้อผิดพลาดที่ไม่เป็นประโยชน์อื่น ๆ นอกจากนี้ยังปรับใช้และทำงานบนเครื่อง 64 บิตบางเครื่อง แต่ไม่ใช่เครื่องอื่น ๆ เราไม่สามารถบอกได้ว่ามีอะไรแตกต่างกันอย่างไร คุณได้แก้ปัญหานี้หรือไม่?
นนท์

2
@nont - ปัญหาคืออะไรมันไม่ใช่การคอมไพล์ 32vs64 บิต
Stephen C

คำตอบ:


94

ใช่ Java bytecode (และซอร์สโค้ด) เป็นแพลตฟอร์มที่ไม่ขึ้นกับโดยสมมติว่าคุณใช้ไลบรารีอิสระของแพลตฟอร์ม 32 กับ 64 บิตไม่ควรสำคัญ


ฉันพบสิ่งนี้ในขณะที่ค้นหาคำถามที่ฉันมี ฉันจึงรันแอปพลิเคชันของฉันภายใต้ JVM 32 บิตและใช้ไลบรารีเนทีฟ 64 บิต มันวิ่งได้ดี แต่เมื่อฉันเรียกใช้แอปพลิเคชันของฉันภายใต้ JVM 64 บิตและใช้ไลบรารีดั้งเดิม 32 บิตมันล้มเหลว จะเป็นไปได้อย่างไร? แค่สงสัย.
Umang Desai

6
@umangdesai ไลบรารีเนทีฟไม่ใช่ไลบรารีอิสระของแพลตฟอร์มดังนั้นจึงไม่มีข้อสันนิษฐาน
Thorbjørn Ravn Andersen

"ไม่ควรสำคัญ" หมายความว่าโค้ดที่คอมไพล์ด้วย 32 บิตjavacจะใช้ประโยชน์จากหน่วยความจำที่มีให้ใน 64 บิตjavaหรือไม่
Marcus Junius Brutus

1
หากคุณถูกต่อยกับสิ่งนี้ให้ระวังไลบรารีเนทีฟที่รวมอยู่ใน jar ที่ใช้งานได้กับแพลตฟอร์มเดียว แต่ไม่ใช่สำหรับไลบรารีที่ทำให้คุณมีปัญหา (หากคุณไม่รู้ว่าฉันหมายถึงอะไรโปรดดูสิ่งนี้stackoverflow.com/a/14051512/155631 )
Matt S.

21

ฉันบังเอิญเรียกใช้แอปพลิเคชัน (ขนาดใหญ่) ของเราบน VM 64 บิตแทนที่จะเป็น VM 32 บิตและไม่ได้สังเกตเห็นจนกระทั่งไลบรารีภายนอกบางส่วน (เรียกโดย JNI) เริ่มล้มเหลว

ข้อมูลซีเรียลบนแพลตฟอร์ม 32 บิตถูกอ่านบนแพลตฟอร์ม 64 บิตโดยไม่มีปัญหาเลย

คุณได้รับปัญหาประเภทใด บางสิ่งได้ผลไม่ใช่อย่างอื่น? คุณลองติด JConsole และอื่น ๆ แล้วมีจุดสูงสุดหรือไม่?

หากคุณมี VM ที่ใหญ่มากคุณอาจพบว่าปัญหา GC ใน 64 บิตอาจส่งผลกระทบต่อคุณ


1
คุณกำลังบอกว่าไลบรารี JNI จะไม่ทำงานใน VM 64 บิตถ้าเป็น 32 บิต?
C. Ross

1
พวกเขาไม่ทำงาน เพื่อนร่วมงานคนหนึ่งรายงานว่าพวกเขาทำ (ซึ่งฉันพบว่าน่าสงสัย - พูดน้อยที่สุด) ฉันสงสัยว่าเขากำลังวิ่งบน Solaris หรือไม่และมีเหตุการณ์บางอย่างเกิดขึ้น ไม่มี; เขาเข้าใจผิดและมันทำงานต่ำกว่า 32 บิต
Fortyrunner

ฉันมีปัญหาคล้ายกันกับไลบรารี JNI ไม่มีความเข้ากันได้ระหว่างไลบรารี 32 บิตและ 64 บิต
Erick Robertson

จำเป็นต้องเปลี่ยน JNI libs ของคุณ คุณสามารถดาวน์โหลดทางเลือก 64 บิตได้จากเว็บไซต์ของผู้จำหน่าย (นั่นเป็นเคล็ดลับสำหรับฉันสำหรับ JNI libs ทั้งหมดที่ฉันใช้)
bvdb

เหล่านี้เป็นไลบรารีภายในและไม่มี 64 บิตเทียบเท่าดังนั้นกลับไปที่ 32 บิตคือลำดับของวัน ..
Fortyrunner

11

ใช่สำหรับคำถามแรกและไม่ใช่สำหรับคำถามที่สอง มันเป็นเครื่องเสมือน ปัญหาของคุณอาจเกี่ยวข้องกับการเปลี่ยนแปลงที่ไม่ระบุในการใช้งานไลบรารีระหว่างเวอร์ชัน แม้ว่ามันอาจจะเป็นสภาพการแข่งขัน

มีห่วงบางอย่างที่ VM ต้องดำเนินการ การอ้างอิงโดยเฉพาะจะได้รับการปฏิบัติในไฟล์คลาสราวกับว่าพวกเขาใช้พื้นที่เดียวกับints บนสแต็ก doubleและlongใช้ช่องอ้างอิงสองช่อง ตัวอย่างเช่นฟิลด์อินสแตนซ์มีการจัดเรียงใหม่บางอย่างที่ VM มักจะดำเนินการต่อไป ทั้งหมดนี้ทำได้ (ค่อนข้าง) โปร่งใส

นอกจากนี้ JVM แบบ 64 บิตบางตัวก็ใช้ "บีบอัด oops" เนื่องจากข้อมูลมีการจัดแนวให้อยู่รอบ ๆ ทุกๆ 8 หรือ 16 ไบต์ที่อยู่สามหรือสี่บิตจึงไร้ประโยชน์ (แม้ว่าบางอัลกอริทึมจะขโมย "เครื่องหมาย" บิตก็ตาม) สิ่งนี้ช่วยให้ข้อมูลแอดเดรส 32 บิต (ดังนั้นจึงใช้แบนด์วิดท์ครึ่งหนึ่งและเร็วกว่า) เพื่อใช้ขนาดฮีป 35- หรือ 36 บิตบนแพลตฟอร์ม 64 บิต


3
คุณทำให้ฉันแปลกใจ. ฉันไม่คิดว่าจะมีรหัสไบต์ 32 บิตหรือรหัสไบต์ 64 บิต
Jon Skeet

3
กำลังอ่านคำตอบของคุณอีกครั้ง - คุณแน่ใจหรือไม่ว่าคุณไม่ได้หมายถึงมันในทางกลับกัน? (ใช่แล้วไม่ใช่)
Jon Skeet

+1 ให้กับ Jon Skeet ฉันเขียนความคิดเห็นเดียวกัน แต่ถูกเรียกไป
Michael Myers

ฉันหมายความว่าไม่ใช่ แต่ด้วยคำถามในทางกลับกัน ได้ย้อนกลับการแก้ไขและแก้ไข (และใส่ข้อมูลเพิ่มเติมอีกเล็กน้อย)
Tom Hawtin - แท็กไลน์

4
@ Jon Skeet: ไม่มีไบต์โค้ด 32 บิตและ 64 บิต แต่เมื่อ JITed พอยน์เตอร์ใน JVM จะเป็น (ปกติ) 32 หรือ 64 บิตขึ้นอยู่กับแพลตฟอร์ม และด้วย OOPS ที่บีบอัดพวกเขาสามารถใช้พอยน์เตอร์ 32 บิตในหลาย ๆ ที่แม้กระทั่งบน JVM 64 บิต ซึ่งช่วยประหยัดหน่วยความจำได้เล็กน้อยและเพิ่มตำแหน่งของรหัสซึ่งจะนำไปสู่ความเร็วที่มากขึ้น
Joachim Sauer

9

รหัสไบต์ทั้งหมดเป็นแบบ 8 บิต (นั่นคือเหตุผลที่เรียกว่ารหัส BYTE) คำแนะนำทั้งหมดมีขนาด 8 บิตหลายขนาด เราพัฒนาบนเครื่อง 32 บิตและเรียกใช้เซิร์ฟเวอร์ของเราด้วย JVM 64 บิต

คุณช่วยให้รายละเอียดเกี่ยวกับปัญหาที่คุณกำลังเผชิญได้หรือไม่? จากนั้นเราอาจมีโอกาสช่วยเหลือคุณ มิฉะนั้นเราจะเดาได้ว่าคุณกำลังมีปัญหาอะไร


8

เว้นแต่คุณจะมีโค้ดเนทีฟ (รหัสเครื่องที่คอมไพล์สำหรับเกมอาร์คิเทคเฉพาะ) โค้ดของคุณจะทำงานได้ดีเท่า ๆ กันใน JVM 32 บิตและ 64 บิต

อย่างไรก็ตามโปรดทราบว่าเนื่องจากแอดเดรสที่ใหญ่กว่า (32 บิตคือ 4 ไบต์ 64 บิตคือ 8 ไบต์) JVM 64 บิตจะต้องใช้หน่วยความจำมากกว่า JVM 32 บิตสำหรับงานเดียวกัน


โปรดทราบว่า JVM 32 บิตบนระบบ 64 บิตอาจมีหน่วยความจำที่พร้อมใช้งานมากกว่า JVM 32 บิตในระบบ 32 บิตดังนั้นจึงอาจเป็นตัวเลือกที่น่าสนใจหากคุณมี "ใช้หน่วยความจำไม่กี่ GB "ใบสมัคร.
Thorbjørn Ravn Andersen

3

ความแตกต่างระหว่าง 32 บิตกับ 64 บิตมีความสำคัญมากขึ้นเมื่อคุณเชื่อมต่อกับไลบรารีดั้งเดิม Java 64 บิตจะไม่สามารถเชื่อมต่อกับ 32 บิตที่ไม่ใช่ Java dll (ผ่าน JNI)


5
คุณไม่ได้ให้อะไรใหม่สำหรับคำถามเก่า ๆ นี้
Austin Henley


0

Java JNI ต้องการไลบรารีระบบปฏิบัติการที่มี "bittiness" เดียวกันกับ JVM หากคุณพยายามสร้างสิ่งที่ขึ้นอยู่กับตัวอย่างเช่นบน IESHIMS.DLL (อยู่ใน% ProgramFiles% \ Internet Explorer) คุณต้องใช้เวอร์ชัน 32 บิตเมื่อ JVM ของคุณเป็น 32 บิตซึ่งเป็นเวอร์ชัน 64 บิตเมื่อ JVM ของคุณเป็น 64 บิต เช่นเดียวกันสำหรับแพลตฟอร์มอื่น ๆ

นอกเหนือจากนั้นคุณควรพร้อม Java bytecode ที่สร้างขึ้น s / b เหมือนกัน

โปรดทราบว่าคุณควรใช้คอมไพเลอร์ Java 64 บิตสำหรับโปรเจ็กต์ขนาดใหญ่เนื่องจากสามารถจัดการกับหน่วยความจำได้มากขึ้น


-5

โย่ผิดตรงไหน! สำหรับธีมนี้ฉันเขียนคำถามถึง oracle คำตอบคือ

"ถ้าคุณคอมไพล์โค้ดของคุณบนเครื่อง 32 บิตโค้ดของคุณควรทำงานบนโปรเซสเซอร์ 32 บิตเท่านั้นหากคุณต้องการรันโค้ดของคุณบน JVM 64 บิตคุณต้องคอมไพล์ไฟล์คลาสของคุณบนเครื่อง 64 บิตโดยใช้ 64 - บิต JDK "


5
โดยปกติโค้ด Java รูปแบบไบต์จะคอมไพล์เหมือนกันไม่ว่าจะเป็นแพลตฟอร์ม 32 บิตหรือ 64 บิต กฎจะแตกต่างกันสำหรับโค้ดเนทีฟ แต่โค้ด Java byte เป็นแบบพกพา
McDowell

4
ใช่ดูเหมือนว่าใครก็ตามที่ Oracle ตอบคำถามของคุณอาจเข้าใจผิดหรือไม่รู้อะไรเกี่ยวกับ JVM
Paŭlo Ebermann
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.