मोनो/.Net जीसी संग्रह के बाद ओएस को वापस आवंटित स्मृति आवंटित करता है? यदि नहीं, क्यों?

Question

मैंने कई बार सुना है कि एक बार सी # प्रबंधित प्रोग्राम ओएस से अधिक मेमोरी का अनुरोध करता है, यह तब तक मुक्त नहीं होता है जब तक कि सिस्टम स्मृति से बाहर न हो। उदाहरण के लिए। जब ऑब्जेक्ट एकत्र किया जाता है, तो यह हटा दिया जाता है, और ऑब्जेक्ट द्वारा कब्जा कर लिया गया स्मृति किसी अन्य प्रबंधित ऑब्जेक्ट द्वारा पुन: उपयोग करने के लिए स्वतंत्र होता है, लेकिन स्मृति स्वयं ऑपरेटिंग सिस्टम पर वापस नहीं आती है (उदाहरण के लिए, यूनिक्स पर मोनो brk/sbrk पर कॉल नहीं करेगा इस प्रक्रिया में उपलब्ध वर्चुअल मेमोरी की मात्रा को उसके आवंटन से पहले जो कुछ भी था उससे कम करें)।

मुझे नहीं पता कि यह वास्तव में होता है या नहीं, लेकिन मैं देख सकता हूं कि मेरे सी # अनुप्रयोग, लिनक्स पर चल रहे हैं, शुरुआत में छोटी मात्रा में स्मृति का उपयोग करते हैं, फिर जब मैं कुछ मेमोरी महंगा करता हूं, तो यह अधिक आवंटित करता है , लेकिन बाद में जब सभी ऑब्जेक्ट हटा दिए जाते हैं (मैं इसे डिफगर्स को डीबग संदेश डालकर सत्यापित कर सकता हूं), स्मृति को मुक्त नहीं किया जाता है। दूसरी तरफ जब मैं उस मेमोरी महंगे ऑपरेशन को फिर से चलाता हूं तो कोई और स्मृति आवंटित नहीं की जाती है। कार्यक्रम केवल समाप्त होने तक उसी मात्रा में स्मृति खाने पर रहता है।

शायद यह मेरी गलतफहमी है कि नेट में जीसी कैसे काम करता है, लेकिन अगर यह वास्तव में इस तरह काम करता है, तो वह क्यों है? आवंटित स्मृति को बाद में सिस्टम में वापस लौटने की बजाय, इसका लाभ क्या है? यह कैसे पता चलेगा कि सिस्टम को इसकी आवश्यकता है या नहीं? अन्य प्रभाव के बारे में क्या है जो इस प्रभाव के कारण ओओएम की वजह से दुर्घटनाग्रस्त हो या शुरू नहीं हो सका?

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

नोट: मैं यह सब लिनक्स में मोनो पर परीक्षण कर रहा था क्योंकि मुझे वास्तव में यह समझने में कठिनाई होती है कि विंडोज़ मेमोरी कैसे प्रबंधित करती है, इसलिए लिनक्स पर डिबगिंग मेरे लिए बहुत आसान है, लिनक्स मेमोरी मैनेजमेंट ओपन सोर्स कोड, विंडोज़ का मेमोरी मैनेजमेंट कर्नेल/नेट मेरे लिए रहस्य है

Answer 1

मेमोरी मैनेजर इस तरह से काम करता है क्योंकि जब आपको इसकी आवश्यकता नहीं होती है तो बहुत सारी अप्रयुक्त सिस्टम मेमोरी होने का कोई फायदा नहीं होता है।

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

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

यदि यह लिनक्स में मोनो के साथ समान नहीं है, तो यह उस विशिष्ट कार्यान्वयन के साथ एक समस्या है।

Answer 2

आम तौर पर, यदि किसी ऐप को एक बार स्मृति की आवश्यकता होती है, तो उसे फिर से इसकी आवश्यकता होगी। स्मृति को वापस ओएस पर वापस दोबारा अनुरोध करने के लिए इसे फिर से अनुरोध करने के लिए ओवरहेड है, और यदि कुछ भी स्मृति नहीं चाहता है: परेशान क्यों?। यह फिर से चाहने के संभावित परिदृश्य के लिए अनुकूलित करने की कोशिश कर रहा है। इसके अतिरिक्त, इसे वापस जारी करने के लिए पूरे/संगत ब्लॉक की आवश्यकता होती है जिसे वापस सौंप दिया जा सकता है, जो कि कॉम्पैक्शन जैसी चीजों पर बहुत विशिष्ट प्रभाव डालता है: यह उतना आसान नहीं है जितना "अरे, मैं इनमें से अधिकतर उपयोग नहीं कर रहा हूं: इसे वापस लें" - यह पता लगाने की आवश्यकता है कि क्या हो सकता है, संभवतः पूर्ण संग्रह और कॉम्पैक्ट (ऑब्जेक्ट्स स्थानांतरित करें) चक्र के बाद जारी किया जा सकता है।