मुझे पता है कि जावा पैडिंग का उपयोग करता है; वस्तुओं को 8 बाइट्स का एक बहु होना चाहिए। हालांकि, मैं इसका उद्देश्य नहीं देखता हूं। इसका क्या उपयोग है? इसका मुख्य उद्देश्य क्या है?जावा ऑब्जेक्ट्स को 8 का बहुमत क्यों होना चाहिए?
इसका उद्देश्य alignment है, जो कुछ जगहों की लागत पर तेज़ी से स्मृति पहुंच की अनुमति देता है। यदि डेटा को असाइन किया गया है, तो प्रोसेसर को स्मृति लोड करने के बाद इसे एक्सेस करने के लिए कुछ बदलाव करने की आवश्यकता है।
इसके अतिरिक्त, कचरा संग्रह को सरल आवंटन इकाई के आकार के आकार को सरल (और बढ़ाया जाता है)।
यह संभावना नहीं है कि जावा को 8 बाइट्स (64-बिट सिस्टम को छोड़कर) की आवश्यकता हो, लेकिन जब जावा बनाया गया था तो 32-बिट आर्किटेक्चर मानक थे, यह संभव है कि जावा मानक में 4-बाइट संरेखण की आवश्यकता हो।
मुझे यह जानकारी [विकिपीडिया] (http://en.wikipedia.org/wiki/Java_performance#Memory_usage) और [जावमेक्स] (http://www.javamex.com/tutorials/memory/object_memory_usage.shtml) पर मिली है कि यह 8 बाइट्स है। लेकिन कचरा संग्रह के लिए एकमात्र उद्देश्य है? – Nando
@ user1110725, कृपया ध्यान से पढ़ें। संरेखण न केवल कचरा संग्रह के लिए बल्कि सामान्य रूप से स्मृति पहुंच के लिए है। – cyroxx
को 0 –
जावा में डेटा प्रकार के आकार 8 बिट्स (बाइट्स नहीं) के गुणक हैं क्योंकि अधिकांश आधुनिक प्रोसेसर में शब्द आकार 8-बिट्स के गुणक हैं: 16-बिट्स, 32-बिट्स, 64-बिट्स। इस तरह किसी ऑब्जेक्ट में एक फ़ील्ड को शब्द या शब्दों में फिट करने के लिए ("गठबंधन") और शब्द के आकार के डेटा पर संचालन के लिए अंतर्निहित प्रोसेसर के निर्देशों का लाभ उठाने के लिए जितना संभव हो उतना कम कचरा बनाया जा सकता है।
नहीं, बाइट्स। अधिकांश (सभी?) जेवीएम अपने डेटा को कम से कम 4 बाइट सीमाओं तक संरेखित करता है, सरणी में छोटे प्राइमेटिव को छोड़कर। – U2EF1
मैं डेटाटाइप के बारे में बात नहीं कर रहा हूं, लेकिन ऑब्जेक्ट। इसके साथ मेरा मतलब है, मेरी अपनी वस्तुएं। वे हमेशा 8 बाइट्स के एक बहु होते हैं। कम से कम, मैं यही पढ़ता हूं। मुझे यह जानकारी [विकिपीडिया] (http://en.wikipedia.org/wiki/Java_performance#Memory_usage) और [जावमेक्स] (http://www.javamex.com/tutorials/memory/object_memory_usage.shtml) पर मिली है। – Nando
स्वीकार्य उत्तर अटकलें (लेकिन आंशिक रूप से सही) है। असली जवाब यहाँ है।
सबसे पहले, @ U2EF1 के क्रेडिट के लिए, 8-बाइट सीमाओं के लाभों में से एक यह है कि 8-बाइट अधिकांश प्रोसेसर पर इष्टतम पहुंच हैं। हालांकि, इसके अलावा निर्णय के लिए और भी कुछ था।
यदि आपके पास 32-बिट संदर्भ हैं, तो आप 2^32 या 4 जीबी मेमोरी को संबोधित कर सकते हैं (व्यावहारिक रूप से आप कम हो जाते हैं, 3.5 जीबी की तरह)। यदि आपके पास 64-बिट संदर्भ हैं, तो आप 2^64 को संबोधित कर सकते हैं, जो मेमोरी के टेराबाइट्स हैं। हालांकि, 64-बिट संदर्भों के साथ, सबकुछ धीमा हो जाता है और अधिक जगह लेती है। यह 64-बिट्स से निपटने वाले 32-बिट प्रोसेसर के ऊपरी हिस्से के कारण है, और कम प्रोसेसर और अधिक कचरा संग्रह के कारण सभी प्रोसेसर अधिक जीसी चक्रों पर है।
तो, रचनाकारों ने एक मध्यम जमीन ली और 35-बिट संदर्भों पर निर्णय लिया, जो 2^35 या 32 जीबी मेमोरी की अनुमति देते हैं और 32-बिट संदर्भों के समान प्रदर्शन लाभ प्राप्त करने के लिए कम जगह लेते हैं। यह 32-बिट संदर्भ ले कर और इसे पढ़ने के दौरान इसे 3 बिट छोड़कर स्थानांतरित किया जाता है, और संदर्भों को संग्रहीत करते समय इसे सही 3 बिट्स स्थानांतरित करता है। इसका मतलब है कि सभी वस्तुओं को 2^3 सीमाओं (8 बाइट्स) पर गठबंधन किया जाना चाहिए। इन्हें संपीड़ित सामान्य ऑब्जेक्ट पॉइंटर्स या संपीड़ित ओप्स कहा जाता है।
64 जीबी मेमोरी तक पहुंचने के लिए 36-बिट संदर्भ क्यों नहीं? खैर, यह एक व्यापारिक था। आपको 16-बाइट संरेखण के लिए बहुत बर्बाद जगह की आवश्यकता होगी, और जहां तक मुझे पता है कि प्रोसेसर के विशाल बहुमत को 8-बाइट संरेखण के विपरीत 16-बाइट संरेखण से कोई गति लाभ नहीं मिलता है।
ध्यान दें कि JVM संपीड़ित ओप्स का उपयोग करके परेशान नहीं करता है जब तक कि अधिकतम मेमोरी 4 जीबी से ऊपर न हो, जो डिफ़ॉल्ट रूप से नहीं होती है। आप वास्तव में उन्हें -XX:+UsedCompressedOops ध्वज के साथ सक्षम कर सकते हैं।
यह 64-बिट सिस्टम पर अतिरिक्त उपलब्ध स्मृति प्रदान करने के लिए 32-बिट वीएम के दिन वापस था। जहां तक मुझे पता है, 64-बिट वीएम के साथ कोई सीमा नहीं है।
स्रोत: जावा प्रदर्शन: परिभाषा गाइड, अध्याय 8
8-बाइट संरेखण का निर्णय संपीड़ित ओओएस सुविधा से काफी पुराना है और 32 बिट जेवीएम पर भी लागू होता है, जो 2 जीबी से अधिक का समर्थन नहीं करता है। आपकी अटकलें कि "* भविष्य के जेवीएम 64-बिट संदर्भों का समर्थन करेंगे *" कोई समझ नहीं आता है, क्योंकि सभी 64 बिट जेवीएम * करते हैं * 64-बिट संदर्भों का समर्थन करते हैं। उनका उपयोग तब किया जाता है जब ढेर 32 जीबी से बड़ा होता है या जब '-XX: -UsedCompressedOops' निर्दिष्ट किया जाता है या पुराने JVM का उपयोग करते समय, जिसमें संपीड़ित ओप्स सुविधा नहीं होती है। – Holger
शायद खराब शब्दों में, लेकिन मेरा मतलब उन संदर्भों का था जो _all_ 64-बिट्स का उपयोग करते हैं, न कि "64-बिट मानों में संग्रहीत संदर्भ" नहीं थे। आखिरी बार मैंने चेक किया (जो थोड़ी देर पहले था), आप एक JVM में 2^64 मेमोरी ढेर का उपयोग नहीं कर सके। –
मुझे आश्चर्य होगा कि अगर आपको कभी भी एक वास्तविक प्रणाली (हार्डवेयर + ऑपरेटिंग सिस्टम) मिलती है जो 2⁶⁴ बाइट आवंटित करने का समर्थन करती है। मैं सोच रहा हूं, चाहे आप समझें, वह कितना बड़ा है। हालांकि, आप अंतर्निहित प्रणाली के रूप में बड़े पैमाने पर एक ढेर का उपयोग कर सकते हैं। यदि आपको लगता है कि ऑपरेटिंग सिस्टम की तुलना में कम से कम 64 बिट जेवीएम का सामना करना पड़ता है, तो आपको अधिक विशिष्ट होना चाहिए। – Holger
यह जेवीएम निर्भर है। –
मुझे ध्यान देने योग्य नहीं है लेकिन मैं हॉटस्पॉट जेवीएम के बारे में बात कर रहा था। – Nando
फिर आप इसे _know_ नहीं करते हैं - आप इसे कहीं भी _read_ करते हैं। –