जेवीएम विकल्प। यह कैसे काम करता है

हर दिन, जावा शब्द अधिक से अधिक एक भाषा के रूप में नहीं माना जाता है, लेकिन एक मंच के रूप में कुख्यात invokeDynamic के लिए धन्यवाद। यही कारण है कि आज मैं एक आभासी जावा मशीन के बारे में बात करना चाहूंगा, अर्थात्, ओरेकल हॉटस्पॉट जेवीएम संस्करण 1.6 और उच्चतर (सर्वर) में तथाकथित प्रदर्शन विकल्पों के बारे में। क्योंकि आज ऐसे लोगों से मिलना लगभग नामुमकिन है जो -Xmx, -Xms और -Xss से ज्यादा कुछ जानते हैं। एक समय, जब मैंने इस विषय में तल्लीन करना शुरू किया, तो मुझे बड़ी मात्रा में दिलचस्प जानकारी मिली, जिसे मैं साझा करना चाहता हूं। शुरुआती बिंदु, ज़ाहिर है, ओरेकल से आधिकारिक दस्तावेज था। और फिर Google, प्रयोग और संचार:

-XX: + DoEcapeAnalysis

मैं शुरू करूँगा, शायद, सबसे दिलचस्प विकल्प के साथ - DoEscapeAnalysis। जैसा कि आप में से कई लोग जानते हैं, आदिम और वस्तु संदर्भ ढेर पर नहीं बने हैं, लेकिन स्ट्रीम स्टैक (हॉटस्पॉट के लिए डिफ़ॉल्ट रूप से 256KB) पर आवंटित किए गए हैं। यह काफी स्पष्ट है कि जावा भाषा सीधे स्टैक पर ऑब्जेक्ट बनाने की अनुमति नहीं देती है। लेकिन आपका JVM 1.6 अपने आप को 14 वें अपडेट के साथ शुरू कर सकता है।

आप इस बारे में पढ़ सकते हैं कि एल्गोरिथ्म खुद यहां कैसे काम करता है (पीडीएफ) । संक्षेप में, तब:

• यदि ऑब्जेक्ट का दायरा उस विधि से परे नहीं जाता है जिसमें इसे बनाया गया है, तो इस तरह के ऑब्जेक्ट को ढेर के बजाय स्टैक फ्रेम पर बनाया जा सकता है (वास्तव में, ऑब्जेक्ट ही नहीं, बल्कि उसके क्षेत्र, जिस वस्तु के साथ ऑब्जेक्ट को प्रतिस्थापित किया गया है) की कुलता;
• यदि ऑब्जेक्ट धारा के दायरे को नहीं छोड़ता है, तो अन्य धाराओं में ऐसी ऑब्जेक्ट तक पहुंच नहीं है, और इसलिए ऑब्जेक्ट पर सभी सिंक्रनाइज़ेशन ऑपरेशन को हटाया जा सकता है।

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

• GlobalEscape - एक वस्तु अन्य धाराओं और अन्य तरीकों से सुलभ है, उदाहरण के लिए एक स्थिर क्षेत्र।
• ArgEscape - ऑब्जेक्ट को एक तर्क के रूप में पारित किया गया था या तर्क ऑब्जेक्ट से इसका एक लिंक है, लेकिन यह स्वयं उस स्ट्रीम के दायरे से बाहर नहीं जाता है जिसमें इसे बनाया गया था।
• NoEscape - ऑब्जेक्ट विधि के दायरे को नहीं छोड़ता है और इसके निर्माण को स्टैक पर धकेल दिया जा सकता है।

विश्लेषण चरण के बाद, जेवीएम खुद पहले से ही एक संभव अनुकूलन का संचालन कर रहा है: यदि नोएस्केप एडाप्टर, तो इसे स्टैक पर बनाया जा सकता है; यदि ऑब्जेक्ट NoEscape या ArgEscape है, तो उस पर सिंक्रनाइज़ेशन ऑपरेशन को हटाया जा सकता है।

यह स्पष्ट किया जाना चाहिए कि वस्तु ही नहीं बल्कि इसके क्षेत्र ढेर पर बनाए गए हैं। चूंकि जेवीएम पूरे ऑब्जेक्ट को अपने क्षेत्रों की समग्रता के साथ बदल देता है (धन्यवाद वालरस को स्पष्ट करने के लिए)।

यह स्पष्ट है कि इस तरह के विश्लेषण के लिए धन्यवाद, कार्यक्रम के व्यक्तिगत भागों का प्रदर्शन काफी बढ़ सकता है। इस तरह सिंथेटिक परीक्षणों में:

for (int i = 0; i < 1000*1000*1000; i++) { Foo foo = new Foo(); } 

निष्पादन की गति 8-15 गुना बढ़ सकती है। यद्यपि, अभ्यास से स्पष्ट रूप से स्पष्ट मामलों पर जिसके बारे में हाल ही में लिखा गया था ( यहां और यहां ) एस्केपएलीस काम नहीं करता है। मुझे संदेह है कि यह स्टैक के आकार के कारण है।

वैसे, StringBuilder और StringBuffer के बारे में प्रसिद्ध विवाद के लिए एस्केपएनालिसिस आंशिक रूप से जिम्मेदार है। यही है, अगर आपने अचानक विधि में एक स्ट्रिंगबर्ल के बजाय एक स्ट्रिंगरबफ़र का उपयोग किया है, तो स्टर्लिंगबफ़र के लिए एस्केपअनालिसिस (यदि ट्रिगर किया गया है) ताले को हटा देगा, जिसके बाद स्ट्रिंगबफ़र पूरी तरह से स्ट्रिंगबर्फर में बदल जाता है।

-XX: + एग्रेसिव ऑफीसर्स

अग्रेसिव ऑप्शंस एक सुपर विकल्प है। इस अर्थ में नहीं कि यह आपके आवेदन के प्रदर्शन को नाटकीय रूप से बढ़ाता है, लेकिन इस अर्थ में कि यह केवल अन्य विकल्पों के मूल्यों को बदलता है (वास्तव में, यह पूरी तरह से सच नहीं है - जेडीके स्रोत कोड में काफी कुछ जगह हैं जहां एग्रेसिवओवर जेवीएम के व्यवहार को बदल सकते हैं। , उल्लिखित विकल्पों के अलावा, यहां के उदाहरणों में से एक)। हम दो आदेशों का उपयोग करके परिवर्तित झंडे की जाँच करेंगे:

 java -server -XX:-AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal > no_aggr java -server -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal > aggr 

निष्पादन के बाद, कमांड के निष्पादन के परिणामों में अंतर इस तरह से देखा गया:

	-AggressiveOpts	+ आक्रामक भाषाएं
AutoBoxCacheMax	128	20000
BiasedLockingStartupDelay	4000	500
EliminateAutoBox	झूठा	सच
OptimizeFill	झूठा	सच
OptimizeStringConcat	झूठा	सच

दूसरे शब्दों में, यह विकल्प जो कुछ भी करता है वह वर्चुअल मशीन के 5 डेटा मापदंडों को बदल देता है। इसके अलावा, संस्करणों के लिए 1.6 अद्यतन 35 और 1.7 अद्यतन 7, कोई अंतर नहीं देखा गया। यह विकल्प डिफ़ॉल्ट रूप से अक्षम है और क्लाइंट मोड में कुछ भी नहीं बदलता है।
आक्रामक अनुकूलन द्वारा जावा का क्या अर्थ है, इस पर विचार करें:

-XX: AutoBoxCacheMax = आकार

वर्चुअल मशीन शुरू करते समय पूर्णांक प्रकारों के लिए कैश्ड मानों की सीमा का विस्तार करने देता है। मैंने पहले ही इस विकल्प का उल्लेख यहां (दूसरा पैराग्राफ) किया है ।

-XX: बायस्ड लॉकिंगस्टार्टअपडेले = देरी

जैसा कि आप जानते हैं, जावा में एक सिंक्रनाइज़ ब्लॉक को 3 प्रकार के तालों में से एक द्वारा दर्शाया जा सकता है:

• झुका हुआ
• पतला
• वसा

आप यहाँ , यहाँ और यहाँ के बारे में अधिक पढ़ सकते हैं।

चूंकि अधिकांश ऑब्जेक्ट (सिंक्रनाइज़) को एक धागे द्वारा अधिकतम 1 द्वारा अवरुद्ध किया जाता है, इस तरह की वस्तुओं को इस थ्रेड के लिए पक्षपाती किया जा सकता है, और स्ट्रीम के अंदर इस ऑब्जेक्ट पर सिंक्रोनाइज़ेशन ऑपरेशन मूल्य में बहुत कम हो जाते हैं। यदि कोई अन्य थ्रेड पक्षपाती ऑब्जेक्ट तक पहुंचने का प्रयास करता है, तो लॉक इस ऑब्जेक्ट के लिए पतले लॉक पर स्विच करता है।

स्वयं को बदलना अपेक्षाकृत महंगा है, इसलिए जेवीएम के शुरू होने में देरी होती है, जो डिफ़ॉल्ट रूप से सभी तालों को पतला बनाता है और यदि कोई प्रतिस्पर्धा का पता नहीं चलता है और कोड का उपयोग उसी धागे से किया जाता है, तो देरी के बाद ऐसे ताले पक्षपातपूर्ण हो जाते हैं। यही है, जेवीएम शुरू में लॉक उपयोग परिदृश्यों को परिभाषित करने की कोशिश करता है और तदनुसार उनके बीच कम स्विच का उपयोग करता है। तदनुसार, BiasedLockingStartupDelay को शून्य पर सेट करते हुए, हम उम्मीद करते हैं कि सिंक्रनाइज़ेशन कोड के मुख्य टुकड़े का उपयोग केवल उसी स्ट्रीम द्वारा किया जाएगा।

-XX: + OptimizeStringConcat

साथ ही काफी दिलचस्प विकल्प भी। समानता में एक पैटर्न को पहचानता है

 StringBuilder().append(...).toString() //   StringBuilder().append(new StringBuiler().append(...).toString()).toString() 

और एक नए संयोजन ऑपरेशन के लिए लगातार मेमोरी आवंटित करने के बजाय, केवल 1 बार मेमोरी आवंटित करने के लिए प्रत्येक कॉन्टेक्नेशन ऑब्जेक्ट के कुल वर्णों की गणना करने का प्रयास है।
दूसरे शब्दों में, यदि हम एक स्ट्रिंग 20 वर्णों के लिए एपेंड () ऑपरेशन को 20 बार लंबा कहते हैं। चार वर्णों की लंबाई एक बार और 400 वर्णों की लंबाई के साथ होगी।

XX: + OptimizeFill

कार्य को गति देने के लिए एरे फिलिंग / कॉपी साइकल को प्रत्यक्ष मशीन निर्देशों से बदल दिया जाता है।
उदाहरण के लिए, निम्न ब्लॉक (Arrays.fill () से लिया गया):

  for (int i=fromIndex; i<toIndex; i++) a[i] = val; 

केवल निचले स्तर के लोगों की तुलना में मेमसेट की समानता में संबंधित प्रोसेसर निर्देशों के साथ पूर्ण प्रतिस्थापन होंगे।

XX: + EliminateAutoBox

नाम के आधार पर, ध्वज को किसी तरह से ऑटोबॉक्सिंग ऑपरेशन की संख्या को कम करना चाहिए। दुर्भाग्य से, मैं अभी भी यह पता नहीं लगा सका कि यह ध्वज क्या कर रहा है। केवल एक चीज जो यह स्पष्ट करने में सक्षम थी कि यह केवल इंटीजर गोले पर लागू होती है।

-XX: + UseCompressedStrings

एक सुंदर विवादास्पद विकल्प, मेरी राय में ... यदि 90 के दशक में, जावा डेवलपर्स ने प्रति चरित्र 2 बाइट्स को नहीं छोड़ा, तो आज ऐसा अनुकूलन बहुत हास्यास्पद लगता है। यदि किसी को अनुमान नहीं है, तो विकल्प वर्ण सरणियों को बाइट सरणियों के साथ स्ट्रिंग में बदल देता है जहां संभव हो (ASCII)। संक्षेप में:

 char[] -> byte[] 

इस प्रकार, महत्वपूर्ण स्मृति बचत संभव है। लेकिन इस तथ्य को देखते हुए कि प्रकार बदल रहा है, कुछ कार्यों के दौरान प्रकार नियंत्रण का ओवरहेड प्रकट होता है। यही है, इस विकल्प के साथ, जेवीएम प्रदर्शन का क्षरण संभव है। दरअसल यही कारण है कि विकल्प डिफ़ॉल्ट रूप से अक्षम है।

-XX: + UseStringCache

काफी रहस्यमय विकल्प, नाम से देखते हुए, इसे किसी तरह लाइनों को कैश करना चाहिए। कैसे? यह स्पष्ट नहीं है। कोई जानकारी नहीं है। हाँ, और कोड कुछ नहीं कर रहा है। मुझे खुशी होगी अगर कोई स्पष्ट कर सकता है।

-XX: + UseCompressedOops

सबसे पहले, कुछ तथ्य:

• 32-बिट JVM में किसी ऑब्जेक्ट को पॉइंटर का आकार 32 बिट्स होता है। 64-बिट में - 64 बिट्स। इसलिए, पहले मामले में, आप आकार में 2 ^ 32 बाइट्स (4 जीबी) के पते की जगह का उपयोग कर सकते हैं, और दूसरे मामले में, 2 ^ 64 बाइट्स।
• जावा में वस्तुओं का आकार 8 बाइट्स का एक बहु है, चाहे वह वर्चुअल मशीन के आकार का हो (यह सभी वर्चुअल मशीनों के लिए सही नहीं है, लेकिन यह हॉटस्पॉट के बारे में है)। यही है, 32-बिट पॉइंटर्स का उपयोग करते समय, अंतिम 3 बिट्स हमेशा शून्य होंगे, वास्तव में, वर्चुअल मशीन वास्तव में 29 बिट्स का उपयोग करती है।

यह विकल्प 64-बिट JVMs के लिए पॉइंटर का आकार 32 बिट्स तक कम करने की अनुमति देता है, लेकिन इस मामले में ढेर का आकार 4 जीबी तक सीमित है, इसलिए, छोटे पॉइंटर के अलावा, 8 बाइट्स के गुणक की संपत्ति का उपयोग किया जाता है। नतीजतन, हमें 32 बिट्स के पॉइंटर्स के साथ 2 ^ 35 बाइट्स (32 जीबी) साइज के एड्रेस स्पेस का उपयोग करने का अवसर मिलता है।
वास्तव में, एक वर्चुअल मशीन के अंदर, हमारे पास ऑब्जेक्ट्स के लिए पॉइंटर्स होते हैं, मेमोरी में विशिष्ट बाइट्स नहीं। यह स्पष्ट है कि इस तरह की धारणाओं (बहुलता के बारे में) के कारण, पॉइंटर्स के रूपांतरण के लिए अतिरिक्त लागत दिखाई देती है। लेकिन अनिवार्य रूप से यह सिर्फ एक शिफ्ट और सम ऑपरेशन है।

स्वयं पॉइंटर्स के आकार को कम करने के अलावा, यह विकल्प ऑब्जेक्ट्स के हेडर को भी कम करता है और बनाई गई ऑब्जेक्ट्स के अंदर सभी प्रकार के संरेखण और शिफ्ट्स को कम करता है, जो एप्लिकेशन मॉडल के आधार पर औसत मेमोरी खपत को 20-60% तक कम करने की अनुमति देता है।

अर्थात्, हमारे पास केवल नुकसान ही हैं:

• अधिकतम ढेर का आकार 32 जीबी तक सीमित है (16 बाइट्स के ऑब्जेक्ट गुणक के साथ JRockit के लिए 64 जीबी);
• अतिरिक्त दिखाई देते हैं। जेवीएम लिंक को देशी और इसके विपरीत में परिवर्तित करने की लागत।

चूंकि विकल्प में अधिकांश अनुप्रयोगों के लिए कुछ फायदे हैं, JDK 6 अपडेट 23 से शुरू होकर यह डिफ़ॉल्ट रूप से सक्षम है, साथ ही साथ JDK 7 में। अधिक जानकारी यहाँ और यहाँ ।

-XX: + हटा दें

एक विकल्प जो उन्हें जोड़कर अनावश्यक ताले को समाप्त करता है। उदाहरण के लिए, निम्नलिखित ब्लॉक:

 synchronized (object) { //doSomething1 } synchronized (object) { //doSomething2 } 

 synchronized (object) { //doSomething3 } //doSomething4 synchronized (object) { //doSomething5 } 

के अनुसार परिवर्तित किया जाएगा

 synchronized (object) { //doSomething1 //doSomething2 } 

 synchronized (object) { //doSomething3 //doSomething4 //doSomething5 } 

यह मॉनिटर पर कब्जा करने के प्रयासों की संख्या को कम करता है।

निष्कर्ष

ओवरबोर्ड में काफी दिलचस्प विकल्प बचे हैं, क्योंकि सभी ~ 700 झंडों को एक लेख में डालना काफी मुश्किल है। मैं विशेष रूप से कलेक्टर को ट्यूनिंग के लिए विकल्पों पर नहीं छूता था, इसलिए यह एक व्यापक और जटिल विषय है और यह कई पदों के योग्य है। मुझे उम्मीद है कि लेख आपके लिए उपयोगी था।