आलेख जावा वर्चुअल मशीन 64-बिट में पॉइंटर संपीड़न के कार्यान्वयन पर ध्यान केंद्रित करेगा, जो कि UseCompressedOops विकल्प द्वारा नियंत्रित किया जाता है और जावा एसई 6u23 के साथ शुरू होने वाले 64-बिट सिस्टम के लिए डिफ़ॉल्ट रूप से सक्षम है।

समस्या का वर्णन

64-बिट JVM में, पॉइंटर्स 32-बिट वाले की तुलना में 2 गुना अधिक (आश्चर्य-चकित) मेमोरी स्पेस लेते हैं। यह 32-बिट आर्किटेक्चर के लिए समान कोड की तुलना में डेटा का आकार 1.5 गुना बढ़ा सकता है। इसी समय, 32-बिट आर्किटेक्चर में, केवल 2 ^ 32 बाइट्स (4 जीबी) को संबोधित किया जा सकता है, जो आधुनिक दुनिया में काफी छोटा है।

आइए एक छोटा सा कार्यक्रम लिखें और देखें कि कितनी बाइट्स में से कौन-कौन सी वस्तुएं पूरी होती हैं:

import java.util.stream.IntStream; import java.util.stream.Stream; class HeapTest { public static void main(String ... args) throws Exception { Integer[] x = IntStream.range(0, 1_000_000).boxed().toArray(Integer[]::new); Thread.sleep(6000000); Stream.of(x).forEach(System.out::println); } } 

यहां हम इंटेगर वर्ग की एक लाख वस्तुओं को उजागर करते हैं और लंबे समय तक सो जाते हैं। अंतिम पंक्ति की आवश्यकता है ताकि संकलक अचानक सरणी के निर्माण की उपेक्षा न करें (हालांकि मेरी मशीन पर, इस पंक्ति के बिना सामान्य रूप से ऑब्जेक्ट बनाए जाते हैं)।

हम प्रोग्राम को अक्षम सूचक संपीड़न के साथ संकलित और चलाते हैं:

 > javac HeapTest.java > java -XX:-UseCompressedOops HeapTest 

Jcmd उपयोगिता का उपयोग करते हुए , हम मेमोरी आवंटन को देखते हैं:

 > jps 45236 HeapTest ... > jcmd 45236 GC.class_histogram 

चित्र से पता चलता है कि वस्तुओं की कुल संख्या 1000128 है , और इन वस्तुओं पर कब्जा करने वाली मेमोरी का आकार 24003072 बाइट्स है । यानी 24 बाइट्स प्रति ऑब्जेक्ट (क्यों ठीक 24 नीचे लिखा जाएगा)।

और यहाँ एक ही प्रोग्राम की मेमोरी है, लेकिन UseCompressedOops के झंडे के साथ:

अब प्रत्येक ऑब्जेक्ट 16 बाइट्स पर कब्जा कर लेता है।
संपीड़न के लाभ स्पष्ट हैं =)

निर्णय

जेवीएम कैसे इंगित करता है? इस तकनीक को कॉम्प्रेस्ड ऊप्स कहा जाता है। ऊप का अर्थ साधारण वस्तु सूचक या साधारण वस्तु सूचक है ।

चाल यह है कि एक 64-बिट सिस्टम में, मेमोरी में डेटा मशीन शब्द के साथ गठबंधन किया जाता है, अर्थात। 8 बाइट्स प्रत्येक। और पते के अंत में हमेशा तीन शून्य बिट्स होते हैं।

यदि आप सूचक को 3 बिट्स द्वारा दाईं ओर स्थानांतरित करके सहेजते हैं (ऑपरेशन को एनकोड कहा जाता है), और उपयोग करने से पहले, 3 बिट्स को बाईं ओर शिफ्ट करें (क्रमशः डिकोड करें ), तो आप 35 बिट्स के आकार के साथ 32-बिट पॉइंटर्स फिट कर सकते हैं, अर्थात 32 जीबी (2 ^ 35 बाइट) तक का पता।

यदि आपके प्रोग्राम के लिए ढेर का आकार 32GB से अधिक है, तो संपीड़न काम करना बंद कर देता है और सभी पॉइंटर्स आकार में 8 बाइट्स बन जाते हैं।

जब UseCompressedOops विकल्प सक्षम होता है , तो निम्न प्रकार के संकेत संपीड़ित होते हैं:

• प्रत्येक वस्तु के लिए कक्षा क्षेत्र
• क्लास फील्ड ऑब्जेक्ट्स
• वस्तुओं की एक सरणी के तत्व।

जेवीएम की वस्तुएं कभी संकुचित नहीं होती हैं। इस मामले में, संपीड़न वर्चुअल मशीन के स्तर पर होता है, न कि बायोटेक पर।

स्मृति में वस्तुओं को रखने के बारे में और पढ़ें

अब, JolM उपयोगिता का उपयोग करें (जावा ऑब्जेक्ट लेआउट) एक नज़र रखने के लिए कि हमारे इंटीगर को विभिन्न JMMs में कितनी मेमोरी लगती है:

 > java -jar jol-cli-0.9-full.jar estimates java.lang.Integer ***** 32-bit VM: ********************************************************** java.lang.Integer object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 8 (object header) N/A 8 4 int Integer.value N/A 12 4 (loss due to the next object alignment) Instance size: 16 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total ***** 64-bit VM: ********************************************************** java.lang.Integer object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 16 (object header) N/A 16 4 int Integer.value N/A 20 4 (loss due to the next object alignment) Instance size: 24 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total ***** 64-bit VM, compressed references enabled: *************************** java.lang.Integer object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int Integer.value N/A Instance size: 16 bytes Space losses: 0 bytes internal + 0 bytes external = 0 bytes total ***** 64-bit VM, compressed references enabled, 16-byte align: ************ java.lang.Integer object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int Integer.value N/A Instance size: 16 bytes Space losses: 0 bytes internal + 0 bytes external = 0 bytes total 

"64-बिट वीएम" और "64-बिट वीएम, संपीड़ित संदर्भ सक्षम" के बीच का अंतर ऑब्जेक्ट हेडर को 4 बाइट्स से कम करना है। प्लस, संपीड़न के बिना मामले में, स्मृति में डेटा संरेखित करने के लिए 4 और बाइट्स जोड़ना आवश्यक हो जाता है।

यह ऑब्जेक्ट हेडर क्या है? इसमें 4 बाइट्स की कमी क्यों हुई?

छवि 12 बाइट्स का ऑब्जेक्ट हेडर दिखाती है, अर्थात UseCompressedOops विकल्प के साथ सक्षम। हेडर में कुछ आंतरिक जेवीएम झंडे होते हैं, साथ ही इस ऑब्जेक्ट के वर्ग के लिए एक सूचक भी होता है। यह देखा जा सकता है कि कक्षा के लिए सूचक 32 बिट्स लेता है। संपीड़न के बिना, यह 64 बिट्स पर कब्जा कर लेगा और ऑब्जेक्ट हेडर का आकार पहले से ही 16 बाइट्स होगा।

वैसे, आप देख सकते हैं कि 16-बाइट संरेखण के लिए एक और विकल्प है। ऐसे में आप मेमोरी को 64 जीबी तक बढ़ा सकते हैं।

विपक्ष की बात

पॉइंटिंग पॉइंटर्स, ज़ाहिर है, एक स्पष्ट माइनस है - हर बार जब पॉइंटर एक्सेस किया जाता है, तो एन्कोड और डिकोड संचालन की लागत। सटीक संख्याएँ आवेदन के अनुसार अलग-अलग होंगी।

उदाहरण के लिए, यहाँ संकुचित और गैर-संपीड़ित बिंदुओं के लिए पॉज़ कचरा संग्रहकर्ता के ठहराव का एक ग्राफ है, यहाँ से जावा जीसी नंबर में लिया गया है - संपीडित OOPs

यह देखा जा सकता है कि संपीड़न चालू होने के साथ, जीसी लंबे समय तक चलता है। आप इस बारे में और अधिक लेख में ही पढ़ सकते हैं (लेख काफी पुराना है - 2013)।

संदर्भ:

हॉटस्पॉट जेवीएम में संपीड़ित उफ़
जेवीएम वस्तुओं को कैसे आवंटित करता है
CompressedOops: जावा में संपीड़ित संदर्भ का परिचय
JVM के संपीड़ित उफ़ के पीछे ट्रिक
जावा हॉटस्पॉट वर्चुअल मशीन प्रदर्शन संवर्द्धन