2009-04-23 23 views
95

क्या 32-बिट जेडीके के खिलाफ 32-बिट जेडीके के खिलाफ 64-बिट जेवीएम में जावा कोड बनाया और संकलित किया जाएगा? या 64-बिट JVM को 64-बिट बाइट कोड की आवश्यकता होती है?जावा 32-बिट बनाम 64-बिट संगतता

थोड़ा और विवरण देने के लिए, मेरे पास कोड है जो 32-बिट जेवीएम चलाने वाले सोलारिस वातावरण में काम कर रहा था, लेकिन अब मुझे जेडीके और वेबलॉगिक सर्वर को 64-बिट में अपग्रेड करने के बाद समस्याएं मिल रही हैं।

+3

कृपया "मुद्दों" को स्पष्ट करें। –

+0

मुझे एक समान समस्या है - 64 बिट वेबलॉगिक सर्वर पर एक वसंत ऐप को तैनात करना। हमें विभिन्न वर्गों को अपवाद नहीं मिलते हैं, और अन्य अनुपयोगी त्रुटियां मिलती हैं। इसके अलावा, यह कुछ 64 बिट मशीनों पर तैनात और चलता है, लेकिन दूसरों को नहीं। हम यह नहीं बता सकते कि क्या अलग है। क्या आपने इसे हल किया? – nont

+2

@ नहीं - जो भी समस्या है, यह 32vs64 बिट संकलन नहीं है। –

उत्तर

90

हां, जावा बाइटकोड (और स्रोत कोड) मंच स्वतंत्र है, मानते हुए कि आप मंच स्वतंत्र पुस्तकालयों का उपयोग करते हैं। 32 बनाम 64 बिट कोई फर्क नहीं पड़ता।

+0

मेरे पास एक प्रश्न की खोज करते समय मैं इसमें भाग गया। इसलिए मैंने 32 बिट जेवीएम के तहत अपना आवेदन चलाया और 64 बिट मूल पुस्तकालय का उपयोग किया। यह ठीक चला गया। लेकिन जब मैं 64 बिट जेवीएम के तहत अपना आवेदन चलाता हूं और 32 बिट देशी लाइब्रेरी का उपयोग करता हूं, तो यह विफल हो जाता है। यह कैसे संभव हो सकता है? बस उत्सुक। –

+6

@umangdesai देशी पुस्तकालय मंच स्वतंत्र पुस्तकालय नहीं हैं, इसलिए धारणा नहीं है। –

+0

क्या "कोई फर्क नहीं पड़ता" का मतलब है कि 32-बिट 'जावैक' के साथ संकलित कोड 64-बिट 'जावा' के साथ उपलब्ध स्मृति का लाभ उठाएगा? –

11

पहले प्रश्न के लिए हाँ और दूसरे प्रश्न के लिए नहीं; यह एक वर्चुअल मशीन है। आपकी समस्याएं शायद संस्करणों के बीच लाइब्रेरी कार्यान्वयन में अनिर्दिष्ट परिवर्तन से संबंधित हैं। हालांकि, यह एक दौड़ की स्थिति कह सकती है।

वीएम को कुछ हुप्स के माध्यम से जाना है। उल्लेखनीय रूप से संदर्भों को क्लास फाइलों में माना जाता है जैसे कि वे स्टैक पर int एस के समान स्थान लेते हैं। double और long दो संदर्भ स्लॉट ले लो। उदाहरण के लिए, कुछ पुनर्गठन कुछ है जो वीएम आमतौर पर किसी भी तरह से चला जाता है। यह सब पारदर्शी रूप से किया जाता है (अपेक्षाकृत)।

इसके अलावा कुछ 64-बिट JVMs "संपीड़ित ओप्स" का उपयोग करते हैं। चूंकि डेटा प्रत्येक 8 या 16 बाइट्स के आसपास गठबंधन होता है, इसलिए पते के तीन या चार बिट बेकार होते हैं (हालांकि कुछ एल्गोरिदम के लिए "चिह्न" बिट चोरी हो सकता है)। यह 64-बिट प्लेटफ़ॉर्म पर 35-या 36-बिट्स के ढेर आकारों का उपयोग करने के लिए 32-बिट एड्रेस डेटा (इसलिए आधा बैंडविड्थ का उपयोग करके, और इसलिए तेज़) का उपयोग करता है।

+3

आप मुझे आश्चर्यचकित करते हैं। मुझे नहीं लगता था कि 32-बिट बाइट कोड या 64-बिट बाइट कोड जैसी चीज थी। –

+3

अपने उत्तर को दोबारा पढ़ना - क्या आप वाकई इसका मतलब नहीं है कि यह दूसरा रास्ता है? (हां फिर नहीं।) –

+0

जॉन स्कीट को +1। मैं एक ही टिप्पणी लिख रहा था लेकिन दूर बुलाया गया। –

20

मैंने 32 बिट वीएम की बजाय 64 बिट वीएम पर गलती से हमारे (बड़े) आवेदन को चलाया और कुछ बाहरी पुस्तकालयों (जिसे जेएनआई द्वारा बुलाया गया) विफल होने तक ध्यान नहीं दिया।

32 बिट प्लेटफार्म पर धारावाहिक डेटा 64 बिट प्लेटफ़ॉर्म पर बिना किसी समस्या के पढ़ा गया था।

आपको किस तरह के मुद्दे मिल रहे हैं? कुछ चीजें काम करते हैं और दूसरों को नहीं? क्या आपने JConsole आदि को जोड़ने का प्रयास किया है और इसके आसपास एक चोटी है?

यदि आपके पास बहुत बड़ा वीएम है तो आप पाएंगे कि 64 बिट में जीसी मुद्दे आपको प्रभावित कर सकते हैं।

+1

क्या आप कह रहे हैं कि यदि वे 32 बिट हैं तो जेएनआई पुस्तकालय 64 बिट वीएम में काम नहीं करेंगे? –

+0

वे हमारे अंदर नहीं थे। लेकिन यह थोड़ी देर के बाद से मैंने कोशिश की – Fortyrunner

+1

वे काम नहीं करते हैं। एक सहयोगी ने बताया था कि उन्होंने (जिसे मुझे संदिग्ध पाया - कम से कम कहने के लिए)। मुझे आश्चर्य हुआ कि क्या वह सोलारिस पर चल रहा था और उस पर कुछ प्रकार का थका हुआ चल रहा था। वहां नहीं था; वह गलत था और यह 32 बिट के तहत चल रहा था। – Fortyrunner

10

सभी बाइट कोड 8-बिट आधारित है। (यही कारण है कि इसे बीईटीई कोड कहा जाता है) सभी निर्देश आकार में 8-बिट्स के एकाधिक हैं। हम 32-बिट मशीनों पर विकसित होते हैं और 64-बिट JVM के साथ हमारे सर्वर चलाते हैं।

क्या आप जिस समस्या का सामना कर रहे हैं उसका कुछ विवरण दे सकते हैं? तब हमें आपकी मदद करने का मौका मिल सकता है। अन्यथा हम अनुमान लगाएंगे कि आप क्या समस्या कर रहे हैं।

8

जब तक आपके पास मूल कोड नहीं है (एक विशिष्ट आर्केटेक्चर के लिए संकलित मशीन कोड) आपका कोड 32-बिट और 64-बिट JVM में समान रूप से अच्छी तरह से चलाएगा।

नोट, हालांकि, बड़े एड्रेस के कारण (32-बिट 4 बाइट्स, 64-बिट 8 बाइट्स है) 64-बिट JVM को उसी कार्य के लिए 32-बिट JVM की तुलना में अधिक मेमोरी की आवश्यकता होगी।

+0

यह भी ध्यान दें कि 64-बिट सिस्टम पर 32-बिट JVM में 32- बिट-जेवीएम 32-बिट सिस्टम पर, इसलिए यदि आपके पास "कुछ जीबी मेमोरी का उपयोग करें" एप्लिकेशन है तो यह एक दिलचस्प विकल्प हो सकता है। –

-5

यो जहां गलत है! इस विषय के लिए मैंने ओरेकल को एक प्रश्न लिखा था। जवाब था।

"यदि आप 32 बिट मशीन पर अपना कोड संकलित करते हैं, तो आपका कोड केवल 32 बिट प्रोसेसर पर चलाना चाहिए। यदि आप 64 बिट JVM पर अपना कोड चलाना चाहते हैं तो आपको 64 बिट पर अपनी कक्षा फ़ाइलों को संकलित करना होगा एक 64-बिट जेडीके का उपयोग कर मशीन। "

+5

[बाइट कोड प्रारूप] (http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html) जावा कोड आमतौर पर 32 बिट या 64 बिट प्लेटफ़ॉर्म पर ध्यान दिए बिना संकलित होता है। _ नियम किसी मूल कोड के लिए अलग हैं लेकिन जावा बाइट कोड पोर्टेबल है ._ – McDowell

+4

हाँ, ऐसा लगता है कि ओरेकल में जो कोई भी आपके प्रश्न का उत्तर दे रहा था या तो उसे गलत समझा गया था या JVM के बारे में कुछ भी नहीं पता था। –

3

32-बिट बनाम 64-बिट अंतर अधिक महत्वपूर्ण हो जाता है जब आप मूल पुस्तकालयों के साथ इंटरफेसिंग करते हैं। 64-बिट जावा 32-बिट गैर-जावा डीएल (जेएनआई के माध्यम से) इंटरफेस करने में सक्षम नहीं होगा

+5

आपने इस पुराने प्रश्न के लिए कुछ भी नया नहीं दिया है। –

0

जावा जेएनआई को जेवीएम के समान "बिटनेस" की ओएस लाइब्रेरी की आवश्यकता होती है। यदि आप ऐसा कुछ बनाने का प्रयास करते हैं जो निर्भर करता है, उदाहरण के लिए, IESHIMS.DLL (% ProgramFiles% \ Internet Explorer में रहता है) पर आपको 32 बिट संस्करण लेने की आवश्यकता है जब आपका JVM 32 बिट है, 64 बिट संस्करण जब आपका JVM 64 बिट है। इसी तरह अन्य प्लेटफार्मों के लिए।

इसके अलावा, आपको पूरा सेट होना चाहिए। उत्पन्न जावा बाइटकोड एस/बी वही।

ध्यान दें कि आपको बड़ी परियोजनाओं के लिए 64 बिट जावा कंपाइलर का उपयोग करना चाहिए क्योंकि यह अधिक स्मृति को संबोधित कर सकता है।

संबंधित मुद्दे