java - 64-बिट जेवीएम के साथ सबसे बड़ा संभव ढेर आकार क्या है?




jvm 64bit (4)

64-बिट मशीन पर 64-बिट ओएस में 64-बिट जेवीएम चलने के लिए, क्या 2 ^ 64 बाइट्स या 16 एक्साबाइट्स की सैद्धांतिक सीमा के अलावा कोई सीमा है?

आपको हार्डवेयर सीमा को ध्यान में रखना होगा। जबकि पॉइंटर्स 64 बिट वर्तमान CPU हो सकते हैं केवल वर्चुअल मेमोरी के 2 ^ 64 बाइट्स से कम पते को संबोधित कर सकते हैं।

असंपीड़ित पॉइंटर्स के साथ हॉटस्पॉट JVM को अपने ढेर के लिए वर्चुअल एड्रेस स्पेस का निरंतर हिस्सा चाहिए। तो हार्डवेयर के बाद दूसरा बाधा ऑपरेटिंग सिस्टम इतना बड़ा हिस्सा प्रदान करता है, सभी ओएस इसका समर्थन नहीं करते हैं।

और तीसरा व्यावहारिकता है। यहां तक ​​कि यदि आपके पास इतना वर्चुअल मेमोरी हो सकती है, तो इसका मतलब यह नहीं है कि सीपीयू उस भौतिक मेमोरी का समर्थन करते हैं, और बिना शारीरिक मेमोरी के आप स्वैपिंग समाप्त कर देंगे, जो जेवीएम के प्रदर्शन को प्रतिकूल रूप से प्रभावित करेगा क्योंकि जीसी को आम तौर पर बड़े हिस्से को छूना पड़ता है ढेर का

जैसा कि अन्य उत्तरों संपीड़ित ओप्स का उल्लेख करते हैं: ऑब्जेक्ट संरेखण को 8 बाइट से अधिक बंप करके संपीड़ित ओप्स के साथ सीमा 32 जीबी से अधिक बढ़ाया जा सकता है

सैद्धांतिक अधिकतम ढेर मान जिसे 32-बिट सिस्टम में -Xmx साथ सेट किया जा सकता है, निश्चित रूप से 2^32 बाइट्स है, लेकिन आम तौर पर (देखें: अधिकतम जेवीएम ढेर आकार को समझना - 32 बिट बनाम 64 बिट ) कोई भी 4 जीबी का उपयोग नहीं कर सकता है।

64-बिट मशीन पर 64-बिट ओएस में 64-बिट जेवीएम चलने के लिए, क्या 2^64 बाइट्स या 16 एक्साबाइट्स की सैद्धांतिक सीमा के अलावा कोई सीमा है?

मुझे पता है कि विभिन्न कारणों (ज्यादातर कचरा संग्रह) के लिए, अत्यधिक बड़े ढेर बुद्धिमान नहीं हो सकते हैं, लेकिन रैम के टेराबाइट्स के साथ सर्वरों के बारे में पढ़ने के प्रकाश में, मैं सोच रहा हूं कि क्या संभव है


जवाब स्पष्ट रूप से JVM कार्यान्वयन पर निर्भर करता है। अज़ुल का दावा है कि उनका जेवीएम

स्मृति के 1/2 टेराबाइट से अधिक तक स्केल कर सकते हैं

"स्केल कर सकते हैं" से वे "कुएं चलाते हैं" का अर्थ है, जैसा कि "सभी पर चलता है" के विपरीत।


यदि आप 32-बिट संदर्भों का उपयोग करना चाहते हैं, तो आपका ढेर 32 जीबी तक सीमित है।

हालांकि, यदि आप 64-बिट संदर्भों का उपयोग करने के इच्छुक हैं, तो आकार आपके ओएस द्वारा सीमित होने की संभावना है, जैसा कि यह 32-बिट जेवीएम के साथ है। उदाहरण के लिए विंडोज 32-बिट पर यह 1.2 से 1.5 जीबी है।

नोट: आप अपने जेवीएम ढेर को मुख्य स्मृति में फिट करना चाहते हैं, आदर्श रूप से एक NUMA क्षेत्र के अंदर। यह बड़ी मशीनों पर लगभग 1 टीबी है। यदि आपका जेवीएम NUMA क्षेत्रों को स्मृति पहुंच प्रदान करता है और विशेष रूप से जीसी में अधिक समय लगेगा। यदि आपका जेवीएम ढेर स्वैपिंग शुरू कर देता है तो इसमें जीसी के लिए घंटों लग सकते हैं, या यहां तक ​​कि अपनी मशीन को अनुपयोगी बना सकते हैं क्योंकि यह स्वैप ड्राइव को थ्रैश करता है।

नोट: यदि आप अपने ढेर में 32-बिट संदर्भों का उपयोग करते हैं तो भी आप बड़ी सीधी मेमोरी और मेमोरी मैप किए गए आकार तक पहुंच सकते हैं। यानी 32 जीबी से ऊपर का उपयोग करें।

हॉटस्पॉट जेवीएम में संपीड़ित ओह

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


विंडोज प्रति प्रक्रिया मेमोरी सीमा लगाता है, आप देख सकते हैं कि यह प्रत्येक संस्करण के लिए क्या here

देख:

User-mode virtual address space for each 64-bit process; With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): x64: 8 TB Intel IPF: 7 TB 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared







jvm-arguments