चंद्रमा का उल्टा भाग

एप्लिकेशन लिखते समय, सबसे महत्वपूर्ण मुद्दों में से एक मेमोरी खपत और जवाबदेही (गति) है।

यह माना जाता है कि कचरा संग्रहकर्ता एक ब्लैक बॉक्स है, जिसके कार्य की भविष्यवाणी नहीं की जा सकती है।

वे यह भी कहते हैं कि .NET में GC व्यावहारिक रूप से अनुकूलन योग्य नहीं है। और साथ ही, आप .NET फ्रेमवर्क कक्षाओं, और CLR, GC, आदि के लिए स्रोत कोड को नहीं देख सकते हैं।

और मैं कहूंगा कि कोई बात नहीं!

इस लेख में हम विचार करेंगे:

• स्मृति में वस्तुओं के स्थान को व्यवस्थित करने की संरचना
• सीएलआर 4.5 पृष्ठभूमि सर्वर जीसी
• उचित कचरा संग्रह
• .NET 4.0+ के लिए कुशल अनुप्रयोग उन्नयन
• उचित मैनुअल मेमोरी प्रबंधन

Placing स्मृति में वस्तुओं को रखने के लिए संगठन संरचना

एक बार मैंने पहले ही सीएलआर वस्तुओं को आकार देने के बारे में लिखा था । लेख को फिर से बेचना नहीं करने के लिए, चलो मुख्य बिंदुओं को याद करते हैं।

चर संदर्भ प्रकारों के लिए, जब CIL अनुदेश newobj का उपयोग करते हैं या, उदाहरण के लिए, C # में नया ऑपरेटर, एक निश्चित-आकार का मान (4 बाइट्स, उदाहरण के लिए x86, टाइप DWORD) जिसमें नियमित ढेर में बनाई गई वस्तु उदाहरण का पता होता है, जिसे स्टैक पर धकेल दिया जाता है (मत भूलना प्रबंधित हीप को स्मॉल ऑब्जेक्ट हीप और लार्ज ऑब्जेक्ट हीप में विभाजित किया गया है - बाद में जीसी पैराग्राफ में)। तो, C ++ में इस मान को ऑब्जेक्ट के लिए पॉइंटर कहा जाता है, और .NET दुनिया में इसे ऑब्जेक्ट के संदर्भ में कहा जाता है।

लिंक किसी भी विधि को निष्पादित करते समय स्टैक पर रहता है, या किसी वर्ग के क्षेत्र में रहता है।

लिंक बनाए बिना आप किसी वैक्यूम में ऑब्जेक्ट नहीं बना सकते।
ताकि वस्तुओं के आकार और एसओएस (स्ट्राइक के पुत्र) , GC.TotalMemory माप, आदि का उपयोग करके किसी भी परीक्षण का आयोजन करने के बारे में कोई अटकल नहीं है। - बस सीएलआर स्रोतों को देखें, या साझा स्रोत कॉमन लैंग्वेज इन्फ्रास्ट्रक्चर 2.0 , जो एक तरह का शोध प्रोजेक्ट है।

प्रत्येक प्रकार का अपना MethodTable है, और एक ही प्रकार की वस्तुओं के सभी उदाहरण एक ही MethodTable को संदर्भित करते हैं। यह तालिका स्वयं प्रकार (इंटरफ़ेस, अमूर्त वर्ग, आदि) के बारे में जानकारी संग्रहीत करती है।

प्रत्येक ऑब्जेक्ट में दो अतिरिक्त फ़ील्ड होती हैं - ऑब्जेक्ट हेडर, जो SyncTableEntry एड्रेस (सिंकब्लॉक प्रविष्टि), और विधि तालिका सूचक (टाइपहैंडल) को संग्रहीत करता है।

SyncTableEntry - एक संरचना जो एक सीएलआर ऑब्जेक्ट के लिए एक लिंक और खुद को सिंकब्लॉक के लिए एक लिंक संग्रहीत करता है।

SyncBlock एक डेटा संरचना है जो किसी भी वस्तु के लिए एक हैश कोड संग्रहीत करता है।

"किसी के लिए" कहने का अर्थ है कि सीएलआर अग्रिम में एक निश्चित संख्या के सिंकब्लॉक को आरंभ करता है। इसके अलावा, जब GetHashCode () या Monitor.Enter () कॉल करते हैं, तो वातावरण बस ऑब्जेक्ट के हेडर में समाप्त SyncBlock के लिए एक सूचक सम्मिलित करता है, जिस तरह से हैश कोड की गणना करता है।

यह GetSyncBlock विधि को कॉल करके किया जाता है (हम फ़ाइल % %\sscli20\clr\src\vm\syncblk.cpp) । विधि के शरीर में, हम निम्नलिखित कोड देख सकते हैं:

 else if ((bits & BIT_SBLK_IS_HASHCODE) != 0) { DWORD hashCode = bits & MASK_HASHCODE; syncBlock->SetHashCode(hashCode); } 

System.Object.GetHashCode विधि SyncBlock :: GetHashCode पद्धति को लागू करके SyncBlock संरचना पर निर्भर करता है।

सीएलआर 2.0 के लिए प्रारंभिक सिंकब्लेक मान 0 है, लेकिन सीएलआर 4.0 के साथ शुरू मूल्य -1 है।

जब आप Monitor.Exit () कॉल करते हैं, तो Syncblk फिर से -1 हो जाता है।

मैं यह भी ध्यान देना चाहूंगा कि सिंकब्लॉक की सरणी अलग मेमोरी में संग्रहीत है, जो जीसी के लिए दुर्गम है ।

ऐसा कैसे? तुम पूछते हो।

जवाब सरल है - कमजोर लिंक। CLR SyncBlock एरे में एक कमजोर लेखन लिंक बनाता है। जब CLR ऑब्जेक्ट मर जाता है, तो SyncBlock अपडेट किया जाता है।

मॉनिटर.ईंटर () पद्धति का कार्यान्वयन प्लेटफॉर्म और स्वयं जेआईटी पर निर्भर करता है। तो SSCLI स्रोत में इस विधि के लिए उपनाम JIT_MonEnter है ।

वस्तुओं को स्मृति और उनके आकारों में रखने के विषय पर लौटते हुए, मैं यह याद रखना चाहूंगा कि किसी भी वस्तु (एक खाली वर्ग) का कोई उदाहरण x86 में कम से कम 12 बाइट्स लेता है, और x64 में पहले से ही 24 बाइट्स हैं।

हम एसओएस शुरू किए बिना इसे सत्यापित करेंगे।

फ़ाइल % %\sscli20\clr\src\vm\object.h

 #define MIN_OBJECT_SIZE (2*sizeof(BYTE*) + sizeof(ObjHeader)) class Object { protected: MethodTable* m_pMethTab; }; class ObjHeader { private: DWORD m_SyncBlockValue; // the Index and the Bits }; 

सीएलआर वस्तुओं के आकार के बारे में उस लेख की टिप्पणियों में, मुझे सिस्टम के आकार की गणना करने की अशुद्धि के लिए फटकार लगाई गई थी। बिना किसी सबूत के।

हालाँकि, मुझे संख्याओं और ... स्रोत कोड पर अधिक भरोसा है!

.NET 4.0 में System.String में निम्नलिखित सदस्य होते हैं:

• m_firstChar
• m_stringLength
• खाली

हम Empty को ध्यान में नहीं रखते हैं, क्योंकि यह एक खाली स्टेटिक स्ट्रिंग है।
m_stringLength स्ट्रिंग की लंबाई को इंगित करती है।

m_firstChar एक यूनिकोड वर्णों की एक सरणी के भंडारण की शुरुआत के लिए एक सूचक (!!!) है, और सरणी में पहला वर्ण नहीं है ।

यहां किसी भी जादू का उपयोग नहीं किया जाता है - सीएलआर केवल ऑफसेट ढूंढता है।

यह सुनिश्चित करने के लिए, आर्क% \ sscli20 \ clr \ src \ vm \ object .h के साथ फ़ाइल% फ़ोल्डर खोलें।

फ़ाइल की शुरुआत में, हम कोड पर टिप्पणी देखते हैं:

 /* * StringObject - String objects are specialized objects for string * storage/retrieval for higher performance */ 

यह स्ट्रिंग डेटा संग्रहीत करने की आंतरिक संरचना है।

अगला, हम StringObject वर्ग और उसके GetBuffer () विधि को ढूंढते हैं ।

 WCHAR* GetBuffer() { LEAF_CONTRACT; _ASSERTE(this); return (WCHAR*)( PTR_HOST_TO_TADDR(this) + offsetof(StringObject, m_Characters) ); } 

खैर, एक बफर (वर्णों की एक सरणी) बस ऑफसेट द्वारा गणना की जाती है।

लेकिन System.String के बारे में क्या?

फ़ाइल% फ़ोल्डर को आर्काइव% \ sscli20 \ clr \ src \ bcl \ system \ string.cs के साथ खोलें

हम निम्नलिखित पंक्तियों को देखते हैं:

 //NOTE NOTE NOTE NOTE //These fields map directly onto the fields in an EE StringObject. See object.h for the layout. // [NonSerialized]private int m_stringLength; [NonSerialized]private char m_firstChar; 

हालाँकि, System.String अपने काम में COMString पर निर्भर करता है, जो कंस्ट्रक्टर को स्वयं लागू करता है, साथ ही साथ कई तरीके (PadLeft, आदि)।
फ्रेमवर्क और आंतरिक C ++ कार्यान्वयन से विधियों के नामों का सही मिलान करने के लिए, मैं आपको % %\sscli20\clr\src\vm\ecall.cpp फ़ाइल % %\sscli20\clr\src\vm\ecall.cpp को देखने की सलाह देता % %\sscli20\clr\src\vm\ecall.cpp
खैर, अंत में यह सुनिश्चित करने के लिए कि m_firstChar एक पॉइंटर है , विचार करें, उदाहरण के लिए, Join the method code का हिस्सा:

 fixed (char* ptr = &text.m_firstChar) { UnSafeCharBuffer unSafeCharBuffer = new UnSafeCharBuffer(ptr, num); unSafeCharBuffer.AppendString(value[startIndex]); for (int j = startIndex + 1; j <= num2; j++) { unSafeCharBuffer.AppendString(separator); unSafeCharBuffer.AppendString(value[j]); } } 

गणना के साथ थोड़ा अलग संस्करण (लेकिन उसी परिणाम के साथ ) प्रसिद्ध जॉन स्कीट का नेतृत्व करता है।

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

इस प्रकार, कॉल ट्री एक FIFO कंटेनर है जिसमें ढेर होते हैं। जब वर्तमान विधि के लिए कॉल समाप्त होता है, तो स्टैक को हटा दिया जाता है और नष्ट कर दिया जाता है, मूल शाखा पर नियंत्रण वापस लौटता है।

जैसा कि मैंने ऊपर लिखा था, चर संदर्भ प्रकारों के लिए, एक निश्चित-आकार का मान (4 बाइट्स, उदाहरण के लिए, x86 के लिए, DWORD टाइप करें) जिसमें एक नियमित ढेर में बनाई गई वस्तु के उदाहरण का पता होता है, जिसे स्टैक पर धकेल दिया जाता है।

डिफ़ॉल्ट रूप से, आदिम प्रकार के उदाहरण जो बॉक्सिंग में शामिल नहीं होते हैं उन्हें स्टैक पर रखा जाता है।

हालांकि, कुछ अनुकूलन के साथ, JIT- तुरंत रैम को दरकिनार करते हुए प्रोसेसर रजिस्टरों में चर के मूल्यों को रख सकता है।

याद रखें कि ऐसा प्रोसेसर रजिस्टर मेमोरी सेल्स का एक ब्लॉक है जो प्रोसेसर के अंदर अल्ट्राफास्ट रैम मेमोरी का निर्माण करता है, जो प्रोसेसर द्वारा ही उपयोग किया जाता है और प्रोग्रामर के लिए सबसे दुर्गम भाग होता है।

CPU कैश जितना बड़ा होगा, सॉफ़्टवेयर प्लेटफ़ॉर्म की परवाह किए बिना, उच्च प्रदर्शन प्राप्त कर सकते हैं।

▌ जीसी डिवाइस

जैसा कि आप जानते हैं, स्मृति प्रबंधन (ऑब्जेक्ट बनाने और नष्ट करने) को कचरा कलेक्टर - उर्फ ​​कचरा कलेक्टर (जीसी) द्वारा नियंत्रित किया जाता है।

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

एक त्वरित टिप्पणी: आभासी स्मृति स्मृति का तार्किक प्रतिनिधित्व है, भौतिक नहीं। भौतिक स्मृति को केवल आवश्यकतानुसार आवंटित किया जाता है। आधुनिक ऑपरेटिंग सिस्टम में प्रत्येक प्रक्रिया को पेजिनेशन (x86, IA-64, PowerPC-64 प्लेटफ़ॉर्म के लिए, अधिकतम आकार 4kB, SPCC - 8 KB) के साथ अधिकतम पता योग्य आकार (32-बिट OS के लिए 4GB) का वर्चुअल पता स्थान आवंटित किया जाता है। इसके लिए धन्यवाद, एक प्रक्रिया के पते स्थान को दूसरे से अलग करना संभव हो जाता है, और डिस्क पर स्वैप का उपयोग करना भी संभव हो जाता है।

स्मृति प्रणाली में वापस आवंटित करने और वापस करने के लिए, GC Win32 फ़ंक्शन VirtualAlloc और VirtualFree का उपयोग करता है।

.NET में गारबेज कलेक्टर जेनरेशनल है, अर्थात प्रबंधित हीप (क्रमशः, ऑब्जेक्ट) पीढ़ियों में विभाजित है। सभी वस्तुओं को जीवन चक्र में कई पीढ़ियों में विभाजित किया जाता है।

वस्तु संदर्भों का स्रोत तथाकथित जीसी जड़ें हैं:

• ढेर
• स्थिर (वैश्विक) वस्तुएं
• अंतिम वस्तुएँ
• अप्रबंधित इंटरोप ऑब्जेक्ट (COM / अप्रबंधित कॉल में भाग लेने वाले CLR)
• प्रोसेसर रजिस्टर
• लिंक के साथ अन्य सीएलआर

इस मामले में, कुल 3 पीढ़ियाँ हैं:

• सृजन ० । इस पीढ़ी की वस्तुओं का जीवन चक्र सबसे छोटा है। आमतौर पर, Gen0 तरीकों के शरीर में निर्मित अस्थायी चर को संदर्भित करता है।
• पीढ़ी १ । इस पीढ़ी का जीवन चक्र भी छोटा है। इसमें एक मध्यवर्ती जीवनकाल वाली वस्तुएं शामिल हैं - Gen0 से Gen2 तक जाने वाली वस्तुएँ।
• पीढ़ी २ । सबसे लंबे समय तक जीवित वस्तुओं का प्रतिनिधित्व करता है। इसके अलावा, 85,000 बाइट्स से बड़ी वस्तुएं स्वचालित रूप से लार्ज ऑब्जेक्ट हीप में गिर जाती हैं और Gen2 के रूप में चिह्नित होती हैं।

प्रत्येक खंड (SOH, LOH) का प्रारंभिक आकार विशिष्ट मशीन पर निर्भर करता है (आमतौर पर डेस्कटॉप के लिए 16 एमबी और सर्वर के लिए 64 एमबी)। मैं यह नोट करना चाहता हूं कि यह वर्चुअल मेमोरी है - एक एप्लिकेशन सामान्य रूप से 5 एमबी भौतिक मेमोरी पर कब्जा कर सकता है।

ऑब्जेक्ट न केवल 85,000 बाइट्स से बड़े हैं, बल्कि कुछ प्रकार के सरणियों को LOH में भी मिलते हैं।

तो 10,600 तत्वों (85000/8 बाइट्स) के आकार के साथ System.Double से एक सरणी LOH में गिरनी चाहिए। हालाँकि, यह पहले से ही 1000+ के आकार में होता है।

प्रबंधित ढेर में वस्तुओं को एक के बाद एक व्यवस्थित किया जाता है, जो, यदि बड़ी संख्या में ऑब्जेक्ट हटाए जाते हैं, तो विखंडन हो सकता है।

हालांकि, इस समस्या को हल करने के लिए, सीएलआर - हमेशा (मैनुअल मेमोरी प्रबंधन के अपवाद के साथ) छोटे ऑब्जेक्ट हीप को डीफ़्रैग्मेन्ट करता है।

प्रक्रिया इस प्रकार है: वर्तमान वस्तुओं को मुक्त मेमोरी (ढेर में रिक्त स्थान जो स्वचालित रूप से गायब हो जाते हैं) में कॉपी किया जाता है।

इस प्रकार, न्यूनतम मेमोरी खपत हासिल की जाती है, हालांकि, इसके लिए एक निश्चित प्रोसेसर समय की आवश्यकता होती है। हालांकि, यह चिंता नहीं करनी चाहिए, क्योंकि Gen0, Gen1 ऑब्जेक्ट्स के लिए, देरी केवल 1 ms की है ।

बड़े ऑब्जेक्ट हीप के बारे में क्या? यह कभी भी डीफ़्रेग्मेंटेड (लगभग कभी नहीं) होता है। इसके लिए बहुत समय की आवश्यकता होगी, जो अनुप्रयोग के प्रदर्शन को प्रभावित कर सकता है। हालांकि, इसका मतलब यह नहीं है कि सीएलआर बिना किसी कारण के अधिक से अधिक मेमोरी का उपभोग करना शुरू कर रहा है। पूर्ण-जीसी (Gen0, Gen1, Gen2) के दौरान, सिस्टम अभी भी ओएस मेमोरी लौटाता है, जो पहले से ही एलओएच (या डीएफ को डीफ़्रैग्मेंट करने वाली वस्तुओं) से मृत वस्तुओं से मुक्त करता है।

इसके अलावा, CLR LOH में एक के बाद एक न केवल एसएचएच में नई वस्तुओं को रखता है, उदाहरण के लिए, बल्कि फुल-जीसी की प्रतीक्षा किए बिना, मुफ्त मेमोरी के स्थानों में भी।
GC लॉन्च नियतात्मक नहीं है, जो GC.Collect () पद्धति को कॉल करने के अपवाद के साथ है।

हालांकि, अभी भी अनुमानित मानदंड हैं जिनके द्वारा यह भविष्यवाणी की जा सकती है (यह याद रखना चाहिए कि नीचे सूचीबद्ध शर्तें अनुमानित हैं और सीएलआर स्वयं आवेदन के व्यवहार के लिए अनुकूल है, बहुत अधिक कचरा कलेक्टर के प्रकार पर निर्भर करता है:

• Gen0 256 केबी तक पहुंचने पर
• जब Gen1 Generation 2 MB तक पहुँच जाता है
• 10 एमबी जेन 2 जेनरेशन तक पहुंचना

कचरा संग्रह भी शुरू होता है जब सिस्टम स्मृति से बाहर निकलता है। CLR इसके लिए Win32 फ़ंक्शन CreateMemoryResourceNotification और QueryMemoryResourceNotification का उपयोग करता है।

एक और बिंदु जब स्मृति के साथ काम करना अप्रबंधित संसाधनों का उपयोग है।

क्योंकि चूंकि मानव रहित संसाधन में कोई भी वस्तु हो सकती है, चाहे उनका जीवनकाल कुछ भी हो और GC नियतात्मक नहीं है, इन उद्देश्यों के लिए एक अंतिम उपाय है।

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

जीसी खत्म होने के बाद, अंतिम वस्तुओं को एक अलग थ्रेड में संसाधित किया जाता है (अंतिम विधि को कॉल करके)।

डिस्पोज़ल पैटर्न का एक उदाहरण कार्यान्वयन:

 class Foo : IDisposable { private bool _disposed; ~Foo() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (!_disposed) { if (disposing) { // Free managed objects } // Free unmanaged objects _disposed = true; } } } 

अब .NET फ्रेमवर्क में उपलब्ध GCs पर विचार करें।

.NET 4.0 से पहले, दो सर्वर और वर्कस्टेशन मोड उपलब्ध थे।

वर्कस्टेशन मोड - जीसी ग्राहक मशीनों पर काम करने के लिए अनुकूलित है। वह प्रोसेसर को अधिक लोड नहीं करने की कोशिश करता है, और यूआई के साथ अनुप्रयोगों के लिए न्यूनतम देरी के साथ भी काम करता है। दो मोड में उपलब्ध है - समानांतर और तुल्यकालिक।

समानांतर मोड में, जीसी 2 पीढ़ी के लिए एक अलग थ्रेड (सामान्य प्राथमिकता के साथ) में लॉन्च किया गया है, जबकि पंचांग पीढ़ियों के काम को अवरुद्ध करना (नई वस्तुओं का आवंटन संभव नहीं है, सभी थ्रेड निलंबित हैं)।

यदि एप्लिकेशन में बहुत अधिक (!!!) बहुत सारी मुफ्त मेमोरी है, तो एसओएच कॉम्पैक्ट नहीं बन जाता है (एप्लिकेशन की जवाबदेही के लिए जीसी बलिदान मेमोरी)।

इस प्रकार, GUI अनुप्रयोगों के लिए वर्कस्टेशन मोड आदर्श है।

इसके अलावा, यदि आपको सर्वर-साइड GC का उपयोग करने की आवश्यकता है, तो आप इसे इस तरह से सक्षम कर सकते हैं:

 <configuration> <runtime> <gcServer enabled="true"/> </runtime> </configuration> 

सत्यापन के लिए, आप कोड में GCSettings.IsServerGC संपत्ति का उपयोग कर सकते हैं।

वर्कस्टेशन समवर्ती जीसी को बंद करने के लिए, हम निम्नलिखित मापदंडों का उपयोग करते हैं:

 <configuration> <runtime> <gcConcurrent enabled="false"/> </runtime> </configuration> 

डिफ़ॉल्ट रूप से, कार्य केंद्र GC के लिए समानांतर मोड सक्षम है। हालांकि, यदि प्रोसेसर सिंगल-कोर है, तो जीसी स्वचालित रूप से सिंक्रोनस मोड में चला जाता है।

अब सर्वर जीसी पर विचार करें।

सर्वर GC प्रबंधित हीप को खंडों में विभाजित करता है, जिनमें से संख्या तार्किक प्रोसेसर की संख्या के बराबर है, उनमें से प्रत्येक को संसाधित करने के लिए एक थ्रेड का उपयोग किया जाता है।

एक त्वरित ध्यान दें: तार्किक प्रोसेसर जरूरी भौतिक प्रोसेसर के अनुरूप नहीं है। कई भौतिक प्रोसेसर (यानी कई सॉकेट) और मल्टी-कोर प्रोसेसर वाले सिस्टम कई तार्किक प्रोसेसर के साथ ओएस प्रदान करते हैं, और कर्नेल (!!!) भी 1 से अधिक तार्किक प्रोसेसर हो सकता है (उदाहरण के लिए, इंटेल हाइपर-थ्रेडिंग तकनीक का उपयोग करते समय)।

इसके अलावा मुख्य अंतरों में से एक GCSettings.LatencyMode प्रॉपर्टी है, जो .NET फ्रेमवर्क 3.5 SP1 (तीन मोड से युक्त) के साथ उपलब्ध है।

डिफ़ॉल्ट रूप से, कार्य केंद्र समवर्ती GC के लिए LatencyMode इंटरएक्टिव, सर्वर - बैच के रूप में सेट किया गया है।

लो-लेटेंसी भी है, लेकिन इसके इस्तेमाल से आउटऑफमेमोरी एक्ससेप्शन हो सकता है इस GC मोड में, फुल कचरा संग्रह केवल उच्च मेमोरी लोड के मामले में होता है। इसके अलावा, यह सर्वर GC के लिए सक्षम नहीं किया जा सकता है।

बैच और इंटरएक्टिव के बीच अंतर क्या है?

क्योंकि सर्वर जीसी प्रबंधित ढेर को कई खंडों में विभाजित करता है (जिनमें से प्रत्येक एक अलग तार्किक प्रोसेसर प्रदान करता है), फिर समानांतर कचरा संग्रह (यदि एक और तार्किक प्रोसेसर पर दूसरा धागा लॉन्च किया गया था) की कोई आवश्यकता नहीं है। यह मोड gcConcurrent पैरामीटर को ओवरराइड करने के लिए बाध्य करता है। यदि gCConcurrent मोड सक्षम है, तो बैच मोड समानांतर (!!!) में आगे कचरा संग्रहण को रोक देगा। बैच वर्कस्टेशन पर अनपेक्षित कचरा संग्रह के बराबर है। इस मोड का उपयोग करते समय, डेटा के बड़े (!!!) का प्रसंस्करण विशेषता है।

यह याद रखना चाहिए कि GCLatencyMode मान को बदलना वर्तमान में चल रहे थ्रेड्स को प्रभावित करता है, जिसका अर्थ है कि रनटाइम को स्वयं प्रभावित करना और अप्रबंधित कोड।

और कब से चूंकि धागे विभिन्न तार्किक प्रोसेसर पर चल सकते हैं, इसलिए जीसी मोड के तत्काल अनुवाद की कोई गारंटी नहीं है।
लेकिन क्या होगा अगर एक और धागा इस मूल्य को बदलना चाहता है। और अगर 100 धागे हैं?

महसूस करें कि एक समस्या बहु-थ्रेडेड अनुप्रयोग के लिए चल रही है? और विशेष रूप से सीएलआर के लिए - आखिरकार, एक अपवाद पर्यावरण में ही फेंक दिया जा सकता है, और एप्लिकेशन कोड में नहीं।

यह ऐसे मामलों के लिए है कि एक विवश निष्पादन क्षेत्र (सीईआर) है - सभी अपवादों (दोनों तुल्यकालिक और अतुल्यकालिक) प्रसंस्करण की गारंटी है।
सीईआर के रूप में चिह्नित कोड ब्लॉक में, रनटाइम को कुछ अतुल्यकालिक अपवादों को फेंकने की अनुमति नहीं है।

उदाहरण के लिए, जब Thread.Abort () को कॉल किया जाता है, तो CER के तहत निष्पादित एक धागा तब तक बाधित नहीं होगा जब तक कि CER- सुरक्षित कोड का निष्पादन पूरा नहीं हो जाता।
इसके अलावा, CLR स्मृति की कमी के साथ ऑपरेशन की गारंटी देने के लिए आरंभीकरण के दौरान सीईआर तैयार करता है।

यह सिफारिश की जाती है कि कोड के बड़े वर्गों के लिए CER का उपयोग न किया जाए इस तरह के कोड के लिए कई प्रतिबंध हैं: मुक्केबाजी, आभासी तरीकों को कॉल करना, प्रतिबिंब के माध्यम से कॉल करना, मॉनिटर.इंटर का उपयोग करना, आदि।

लेकिन चलो इस मामले में तल्लीन न करें और देखें कि कैसे लॅटेंसीमोड मोड को सुरक्षित रूप से स्विच किया जाए।

 var oldMode = GCSettings.LatencyMode; System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions(); try { GCSettings.LatencyMode = GCLatencyMode.Batch; //       } finally { GCSettings.LatencyMode = oldMode; } 

खैर, हमने .NET में GC के काम के मुख्य भाग की पहले ही जांच कर ली है - कोई सवाल नहीं?

निश्चित रूप से नहीं? और क्या यह आपको परेशान नहीं करता है?

हम्म ... वास्तव में पंचांग पीढ़ियों में नई वस्तुओं को आवंटित करने की असंभवता का सवाल नहीं था?

और यहाँ .NET कमांड है - हाँ :)

अब हमारे पास वर्कस्टेशन मोड (.NET 4.5 और सर्वर के साथ शुरू) के लिए नए बैकग्राउंड जीसी तक पहुंच है।

इसके निर्माण का उद्देश्य विशेष रूप से Gen2 में पूर्ण-जीसी के साथ देरी को कम करना था।

पृष्ठभूमि जीसी एक ही समवर्ती जीसी है, एक अपवाद के साथ - पूर्ण-जीसी के साथ, नई वस्तुओं को आवंटित करने के लिए पंचांग पीढ़ियों को अवरुद्ध नहीं किया जाता है।

सहमत हूँ कि Gen2 और LOH को संभालना काफी महंगा है। और अवरुद्ध करना Gen0, Gen1 - अर्थात आवेदन के सामान्य संचालन में देरी (कुछ स्थितियों में) हो सकती है।

नए GC द्वारा संबोधित एक और मुद्दा नई वस्तुओं को आवंटित करने में देरी है जब प्रबंधित हीप का आकार (16 एमबी - डेस्कटॉप, 64 - सर्वर) तक पहुंच गया है।



अब, इस स्थिति को रोकने के लिए, न केवल Gen2 कार्यों के लिए पृष्ठभूमि थ्रेड, बल्कि अग्रगामी धागा (हाँ, हमारे पास भी फोरग्राउंड GC है), जो पंचांग पीढ़ियों से मृत वस्तुओं को चिह्नित करता है और Gen2 के साथ वर्तमान पंचांग पीढ़ियों को जोड़ती है (क्योंकि .combining कॉपी करने से कम खर्चीला ऑपरेशन है) और उन्हें बैकग्राउंड थ्रेड प्रोसेसिंग में ट्रांसफर किया जाता है, जिससे आप नई वस्तुओं के लिए मेमोरी आवंटित कर सकते हैं (मैं आपको याद दिलाता हूं कि बैकग्राउंड GC Gen0 में Gen1 को Gen2 के लिए GC ऑपरेशन के दौरान ब्लॉक नहीं किया गया है)।



विलंब की संख्या में कमी की तुलना नीचे के ग्राफ में की जा सकती है:

Management मैनुअल मेमोरी प्रबंधन

सीएलआर की सबसे दिलचस्प और असामान्य विशेषताओं में से एक और, विशेष रूप से, सी # मैनुअल मेमोरी मैनेजमेंट है, अर्थात्। संकेत के साथ काम करते हैं।

सामान्य तौर पर, यह .NET टाइप-पॉइंटर टाइप का तीसरा प्रकार है। यह किसी भी प्रकार के विशिष्ट उदाहरण के लिए DWORD पते का प्रतिनिधित्व करता है। यानी हम संदर्भ प्रकार उपलब्ध नहीं हैं।

लेकिन हम अनवांटेड कोड के साथ भी काम कर सकते हैं।

ऐसे उद्देश्यों के लिए, संरचना System.Runtime.InteropServices.GCHandle बनाया गया है - एक निश्चित पते के साथ ऑब्जेक्ट जो अप्रबंधित मेमोरी से प्रबंधित ऑब्जेक्ट तक पहुंचने की क्षमता प्रदान करते हैं।

GCHandle के लिए, CLR प्रत्येक AppDomain के लिए एक अलग तालिका का उपयोग करता है।
GCHandle को नष्ट कर दिया जाता है जब GCHandle.Free () कहा जाता है, या जब AppDomain उतार दिया जाता है।

बनाने के लिए, GChandle.Alloc () विधि का उपयोग करें।
निम्नलिखित आवंटन मोड उपलब्ध हैं:

• साधारण
• कमज़ोर
• कमजोर ट्रैक पुनरुत्थान
• पिन की गई

GCHandle के बारे में अधिक जानकारी - MSDN ।

जब मैनुअल मेमोरी हैंडलिंग की आवश्यकता हो सकती है, तो आप पूछें

उदाहरण के लिए, बाइट्स की एक सरणी को कॉपी करने के लिए।

 static unsafe void Copy(byte[] source, int sourceOffset, byte[] target, int targetOffset, int count) { fixed (byte* pSource = source, pTarget = target) { // Set the starting points in source and target for the copying. byte* ps = pSource + sourceOffset; byte* pt = pTarget + targetOffset; // Copy the specified number of bytes from source to target. for (int i = 0; i < count; i++) { *pt = *ps; pt++; ps++; } } } 

याद रखें कि GC SOH को डीफ़्रैग्मेन्ट करता है? कुछ स्थितियों में, ढेर पर वस्तुओं को ठीक करने से एसओएच के अयोग्य डीफ़्रैग्मेन्टेशन हो सकते हैं।

वस्तुओं के पते लगातार बदल रहे हैं (.NET में हम इसे महसूस नहीं करते हैं - पर्यावरण स्वयं लिंक को अपडेट करता है)। लेकिन अनवांटेड कोड के लिए, यह अनुमेय नहीं है।

|| कूड़ा उठाने वाले का उचित विन्यास || .NET 4.0+ के बारे में प्रश्न

.NET 2.0 में लिखा गया एक एप्लिकेशन कोड की एक लाइन को बदलने या फिर से जमा किए बिना आसानी से .NET 4.0 पर काम कर सकता है।



[ .NET फ्रेमवर्क संस्करण और निर्भरता ]

.NET 1.1 को समीक्षा से बाहर रखा जाना चाहिए, क्योंकि आधुनिक जिसे हम जानते हैं वह संस्करण २.० से शुरू होता है।

.NET 3.5 में CLR 2.0, संस्करण 2.0 + नई लाइब्रेरी 3.0 + 3.5 के लिए हैं। मेमोरी में कोई महत्वपूर्ण परिवर्तन, मल्टीथ्रेडिंग, अपवाद हैंडलिंग आदि। नहीं हुआ।

लेकिन .NET 4.0 बहुत अच्छे नवाचार लेकर आया है:

• नया सीएलआर
• नया जीसी
• नई प्रणाली अपवाद हैंडलिंग प्रणाली
• नया धागा पूल
• नया सुरक्षा मॉडल

CLR 4.0 के तहत CLR 2.0 एप्लिकेशन चलाने के लिए, आपको निम्नलिखित पैरामीटर निर्दिष्ट करने होंगे:

 <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup> </configuration> 

पुराने सुरक्षा मॉडल का उपयोग करने के लिए:

 <runtime> <NetFx40_LegacySecurityPolicy enabled="true"/> </runtime> 

सिस्टम एसईएच अपवादों की हैंडलिंग बदल गई है, लेकिन पिछड़े संगतता के लिए, हम कॉन्फ़िगरेशन फ़ाइल में निम्न पंक्तियाँ जोड़ते हैं:

 <configuration> <runtime> <legacyCorruptedStateExceptionsPolicy enabled="true"/> </runtime> </configuration> 

यदि आपका आवेदन भी मूल कोड का उपयोग करता है, तो:

 <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup> 

इस प्रकार, कोड की एक भी लाइन को बदलने और पुन: जमा किए बिना, हम सुरक्षित रूप से .NET 4.0 का उपयोग कर सकते हैं।

Or प्रोसेसर रजिस्टर || FastCall

JIT द्वारा किया गया पहला अनुकूलन VC ++ संकलक में निहित अनुकूलन है, जिसका अर्थ है FastCall।

विधि का सार यह है कि विधि के पहले 2 पैरामीटर ईसीएक्स, ईडीएक्स रजिस्टरों को लिखे गए हैं।

X64 प्लेटफॉर्म के साथ - RCX, RDX, R8, R9 रजिस्टर का उपयोग किया जाता है।
यह क्या देता है?

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

 class Program { static void Main(string[] args) { int startIndex = 1; int endIndex = 2; int x = 3; int y = 5; int result = Compute(startIndex, endIndex, x, y); Console.WriteLine(result); } public static int Compute(int startIndex, int endIndex, int x, int y) { int result = 0; for (int i = startIndex; i < endIndex; i++) { result += x * startIndex + y * endIndex; } return result; } } 

तो उपरोक्त कोड के लिए, वैरिएबल startIndex और endIndex ECX, EDX रजिस्टर, बाकी (x, y) स्टैक पर स्थित होंगे।

चेक करें - ऐसा करने के लिए, डिबगर चलाएं।

वर्तमान रजिस्टरों को देखने के लिए, कमांड टाइप करें CTRL + D, R।



उत्पन्न कोडांतरक को देखने के लिए CTRL + ALT + D।

---

मुझे उम्मीद है कि लेख उपयोगी और दिलचस्प होगा!

आपका ध्यान के लिए धन्यवाद!