कचरा संग्रह (कंप्यूटर विज्ञान)

From alpha
Jump to navigation Jump to search

लिस्प (प्रोग्रामिंग भाषा) में स्टॉप-एंड-कॉपी कचरा संग्रह:[1]मेमोरी को वर्किंग और फ्री मेमोरी में बांटा गया है; नई वस्तुओं को पूर्व में आवंटित किया गया है। जब यह भर जाता है (चित्रित), कचरा संग्रह किया जाता है: अभी भी उपयोग में आने वाली सभी डेटा संरचनाएं पॉइंटर ट्रेसिंग द्वारा स्थित हैं और मुक्त मेमोरी में लगातार स्थानों में कॉपी की जाती हैं।
उसके बाद, कार्यशील मेमोरी सामग्री को संपीड़ित प्रतिलिपि के पक्ष में छोड़ दिया जाता है, और कार्यशील और मुक्त मेमोरी की भूमिका का आदान-प्रदान (चित्रित) किया जाता है।

कंप्यूटर विज्ञान में, कचरा संग्रह (जीसी) स्वत: स्मृति प्रबंधन का एक रूप है। गारबेज कलेक्टर स्मृति को पुनः प्राप्त करने का प्रयास करता है जिसे कार्यक्रम द्वारा आवंटित किया गया था, लेकिन अब इसका संदर्भ नहीं दिया जाता है; ऐसी मेमोरी को 'कचरा (कंप्यूटर विज्ञान)' कहा जाता है। लिस्प (प्रोग्रामिंग लैंग्वेज) में मैनुअल मेमोरी मैनेजमेंट को आसान बनाने के लिए 1959 के आसपास अमेरिकी कंप्यूटर वैज्ञानिक जॉन मैकार्थी (कंप्यूटर वैज्ञानिक) द्वारा कचरा संग्रह का आविष्कार किया गया था।[2]

कचरा संग्रह प्रोग्रामर को मैन्युअल मेमोरी प्रबंधन करने से राहत देता है, जहां प्रोग्रामर निर्दिष्ट करता है कि किन वस्तुओं को डी-आवंटित करना है और मेमोरी सिस्टम में वापस आना है और ऐसा कब करना है।[3] अन्य, इसी तरह की तकनीकों में स्टैक-आधारित मेमोरी आवंटन, क्षेत्र अनुमान और मेमोरी स्वामित्व और उनके संयोजन शामिल हैं। कचरा संग्रह कार्यक्रम के कुल प्रसंस्करण समय का एक महत्वपूर्ण हिस्सा ले सकता है, और परिणामस्वरूप कंप्यूटर के प्रदर्शन को प्रभावित कर सकता है।

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

सिंहावलोकन

कई प्रोग्रामिंग भाषाओं को कचरा संग्रह की आवश्यकता होती है, या तो भाषा विनिर्देश (उदाहरण के लिए, आरपीएल (प्रोग्रामिंग भाषा), जावा (प्रोग्रामिंग भाषा), सी शार्प (प्रोग्रामिंग भाषा) | सी #, डी (प्रोग्रामिंग भाषा),[4]जाओ (प्रोग्रामिंग भाषा), और अधिकांश भाषा का अंकन) या प्रभावी रूप से व्यावहारिक कार्यान्वयन के लिए (जैसे, लैम्ब्डा कैलकुलस जैसी औपचारिक भाषाएँ)। इन्हें कचरा-संग्रहित भाषाएँ कहा जाता है। अन्य भाषाओं, जैसे सी (प्रोग्रामिंग भाषा) और सी ++, को मैन्युअल मेमोरी प्रबंधन के साथ उपयोग करने के लिए डिज़ाइन किया गया था, लेकिन कचरा-एकत्रित कार्यान्वयन उपलब्ध हैं। कुछ भाषाएँ, जैसे Ada (प्रोग्रामिंग लैंग्वेज), मॉड्यूल -3, और C++/CLI, कचरा संग्रह और मैन्युअल मेमोरी प्रबंधन दोनों को एक ही एप्लिकेशन में एकत्रित और मैन्युअल रूप से प्रबंधित वस्तुओं के लिए अलग हीप (डेटा संरचना) का उपयोग करके सह-अस्तित्व की अनुमति देती हैं। . अभी भी अन्य, जैसे डी (प्रोग्रामिंग लैंग्वेज), कचरा-संग्रहित हैं, लेकिन उपयोगकर्ता को वस्तुओं को मैन्युअल रूप से हटाने या गति की आवश्यकता होने पर पूरी तरह से कचरा संग्रह को अक्षम करने की अनुमति देता है।

हालाँकि कई भाषाएँ GC को उनके संकलक और रनटाइम सिस्टम में एकीकृत करती हैं, पोस्ट-हॉक GC सिस्टम भी मौजूद हैं, जैसे कि स्वचालित संदर्भ गिनती (ARC)। इनमें से कुछ पोस्ट-हॉक जीसी सिस्टमों को पुनर्संकलन की आवश्यकता नहीं होती है। सामान्य जीसी से अलग करने के लिए पोस्ट-हॉक जीसी को कभी-कभी कूड़े का संग्रह कहा जाता है।[5]

लाभ

जीसी प्रोग्रामर को मैन्युअल रूप से मेमोरी डी-आवंटन से मुक्त करता है। यह कुछ प्रकार के बग (सॉफ़्टवेयर) से बचने में मदद करता है:

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

नुकसान

किस मेमोरी को खाली करना है, यह तय करने के लिए GC कंप्यूटिंग संसाधनों का उपयोग करता है। इसलिए, स्रोत कोड में मैन्युअल रूप से ऑब्जेक्ट लाइफटाइम को एनोटेट नहीं करने की सुविधा के लिए जुर्माना ओवरहेड (कंप्यूटिंग) है, जो प्रोग्राम के प्रदर्शन को खराब कर सकता है।[6]2005 के एक सहकर्मी-समीक्षित पेपर ने निष्कर्ष निकाला कि जीसी को इस ओवरहेड की भरपाई करने के लिए और आदर्शीकृत स्पष्ट स्मृति प्रबंधन का उपयोग करके समान कार्यक्रम के रूप में तेजी से प्रदर्शन करने के लिए पांच गुना मेमोरी की आवश्यकता होती है। हालाँकि तुलना एक ओरेकल मशीन का उपयोग करके डीलोकेशन कॉल डालने से उत्पन्न प्रोग्राम से की जाती है, जिसे एक प्रोफाइलर के तहत चलने वाले कार्यक्रमों से ट्रेस इकट्ठा करके कार्यान्वित किया जाता है, और प्रोग्राम केवल एक विशेष निष्पादन के लिए सही होता है।[7]स्मृति पदानुक्रम प्रभावों के साथ सहभागिता इस ओवरहेड को उन परिस्थितियों में असहनीय बना सकती है जो नियमित परीक्षण में भविष्यवाणी करने या पता लगाने में कठिन हैं। प्रदर्शन पर प्रभाव Apple द्वारा iOS में कचरा संग्रह को न अपनाने के कारण के रूप में दिया गया था, बावजूद इसके कि यह सबसे वांछित विशेषता है।[8]

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

रणनीतियाँ

ट्रेसिंग

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

संदर्भ गिनती

संदर्भ गिनती कचरा संग्रह वह जगह है जहां प्रत्येक वस्तु के संदर्भों की संख्या की गणना होती है। गारबेज की पहचान शून्य की रेफरेंस काउंट होने से की जाती है। किसी वस्तु की संदर्भ संख्या तब बढ़ जाती है जब उसके लिए एक संदर्भ बनाया जाता है, और जब एक संदर्भ नष्ट हो जाता है तो उसे कम कर दिया जाता है। जब गिनती शून्य तक पहुँच जाती है, तो वस्तु की स्मृति पुनः प्राप्त हो जाती है।[9]

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

रेफरेंस काउंटिंग के कई नुकसान हैं; इसे आम तौर पर अधिक परिष्कृत एल्गोरिदम द्वारा हल या कम किया जा सकता है:

चक्र
यदि दो या दो से अधिक वस्तुएँ एक-दूसरे को संदर्भित करती हैं, तो वे एक चक्र बना सकते हैं जिससे न तो एकत्र किया जाएगा क्योंकि उनके पारस्परिक संदर्भ कभी भी उनकी संदर्भ संख्या को शून्य नहीं होने देंगे। संदर्भ गिनती (सीपीथॉन में एक की तरह) का उपयोग करने वाले कुछ कचरा संग्रह सिस्टम इस मुद्दे से निपटने के लिए विशिष्ट चक्र-पता लगाने वाले एल्गोरिदम का उपयोग करते हैं।[10]एक और रणनीति बैकपॉइंटर्स के लिए कमजोर संदर्भों का उपयोग करना है जो चक्र बनाते हैं। संदर्भ गिनती के तहत, एक कमजोर संदर्भ ट्रेसिंग कचरा संग्राहक के तहत एक कमजोर संदर्भ के समान होता है। यह एक विशेष संदर्भ वस्तु है जिसका अस्तित्व दिग्दर्शन वस्तु की संदर्भ संख्या में वृद्धि नहीं करता है। इसके अलावा, एक कमजोर संदर्भ सुरक्षित है क्योंकि जब संदर्भित वस्तु कचरा बन जाती है, तो इसके लिए कोई भी कमजोर संदर्भ समाप्त हो जाता है, न कि लटकने की अनुमति दी जाती है, जिसका अर्थ है कि यह एक अनुमानित मूल्य में बदल जाता है, जैसे कि एक अशक्त संदर्भ।
स्पेस ओवरहेड (रेफरेंस काउंट)
रेफरेंस काउंटिंग के लिए प्रत्येक ऑब्जेक्ट को उसकी रेफरेंस काउंट को स्टोर करने के लिए स्पेस आवंटित करने की आवश्यकता होती है। काउंट को ऑब्जेक्ट की मेमोरी के पास या साइड टेबल में कहीं और स्टोर किया जा सकता है, लेकिन किसी भी स्थिति में, हर एक रेफरेंस-काउंटेड ऑब्जेक्ट को इसके रेफरेंस काउंट के लिए अतिरिक्त स्टोरेज की आवश्यकता होती है। एक अहस्ताक्षरित सूचक के आकार के साथ मेमोरी स्पेस आमतौर पर इस कार्य के लिए उपयोग किया जाता है, जिसका अर्थ है कि प्रत्येक वस्तु के लिए 32 या 64 बिट संदर्भ गणना भंडारण आवंटित किया जाना चाहिए। कुछ प्रणालियों पर, ऑब्जेक्ट की स्मृति के अप्रयुक्त क्षेत्रों में संदर्भ गणना को संग्रहीत करने के लिए टैग किए गए सूचक का उपयोग करके इस ओवरहेड को कम करना संभव हो सकता है। अक्सर, एक आर्किटेक्चर वास्तव में प्रोग्राम को स्मृति पतों की पूरी श्रृंखला तक पहुंचने की अनुमति नहीं देता है जो उसके मूल सूचक आकार में संग्रहीत किया जा सकता है; पते में कुछ उच्च बिट्स को या तो अनदेखा किया जाता है या शून्य होना आवश्यक है। यदि किसी वस्तु के पास एक निश्चित स्थान पर एक सूचक है, तो संदर्भ संख्या को सूचक के अप्रयुक्त बिट्स में संग्रहीत किया जा सकता है। उदाहरण के लिए, उद्देश्य सी में प्रत्येक वस्तु की स्मृति की शुरुआत में उसकी कक्षा (कंप्यूटर प्रोग्रामिंग) के लिए एक सूचक होता है; IOS 7 का उपयोग करते हुए ARM64 आर्किटेक्चर पर, इस क्लास पॉइंटर के 19 अप्रयुक्त बिट्स का उपयोग ऑब्जेक्ट के रेफरेंस काउंट को स्टोर करने के लिए किया जाता है।[11][12]
स्पीड ओवरहेड (वृद्धि/कमी)
भोले-भाले कार्यान्वयन में, संदर्भ के प्रत्येक असाइनमेंट और दायरे से बाहर होने वाले प्रत्येक संदर्भ में अक्सर एक या अधिक संदर्भ काउंटरों के संशोधन की आवश्यकता होती है। हालाँकि, एक सामान्य मामले में जब किसी बाहरी दायरे के चर से एक आंतरिक दायरे के चर में एक संदर्भ की नकल की जाती है, जैसे कि आंतरिक चर का जीवनकाल बाहरी के जीवनकाल से घिरा होता है, तो संदर्भ वृद्धि को समाप्त किया जा सकता है। बाहरी चर संदर्भ का मालिक है। प्रोग्रामिंग भाषा सी ++ में, इस तकनीक को आसानी से कार्यान्वित किया जाता है और इसके उपयोग के साथ प्रदर्शित किया जाता है const संदर्भ। सी ++ में संदर्भ गणना आमतौर पर स्मार्ट सूचक्स का उपयोग करके कार्यान्वित की जाती है[13]जिनके निर्माता, विध्वंसक और असाइनमेंट ऑपरेटर संदर्भों का प्रबंधन करते हैं। एक स्मार्ट पॉइंटर को एक फ़ंक्शन के संदर्भ में पास किया जा सकता है, जो एक नए स्मार्ट पॉइंटर को कॉपी-निर्माण करने की आवश्यकता से बचा जाता है (जो फ़ंक्शन में प्रवेश पर संदर्भ संख्या को बढ़ाएगा और बाहर निकलने पर इसे कम करेगा)। इसके बजाय फ़ंक्शन स्मार्ट पॉइंटर का संदर्भ प्राप्त करता है जो सस्ते में निर्मित होता है। संदर्भ गणना की Deutsch-बॉब्रो विधि इस तथ्य पर निर्भर करती है कि अधिकांश संदर्भ गणना अद्यतन वास्तव में स्थानीय चरों में संग्रहीत संदर्भों द्वारा उत्पन्न होते हैं। यह इन संदर्भों को अनदेखा करता है, केवल हीप में संदर्भों की गिनती करता है, लेकिन इससे पहले कि संदर्भ संख्या शून्य के साथ किसी वस्तु को हटाया जा सके, सिस्टम को स्टैक के स्कैन के साथ सत्यापित करना चाहिए और यह दर्ज करना चाहिए कि इसके लिए कोई अन्य संदर्भ अभी भी मौजूद नहीं है। लेवानोनी और एरेज़ पेट्रैंक द्वारा पेश किए गए अपडेट कोलेसिंग द्वारा काउंटर अपडेट पर ओवरहेड में और अधिक कमी प्राप्त की जा सकती है।[14][15]एक सूचक पर विचार करें कि निष्पादन के दिए गए अंतराल में कई बार अद्यतन किया जाता है। यह पहले किसी वस्तु की ओर इशारा करता है O1, फिर किसी वस्तु के लिए O2, और इसी तरह अंतराल के अंत तक यह किसी वस्तु की ओर इशारा करता है On. एक संदर्भ गणना एल्गोरिथ्म आमतौर पर निष्पादित होगा rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. लेकिन इनमें से अधिकतर अद्यतन बेमानी हैं। अंतराल के अंत में संदर्भ गणना का उचित मूल्यांकन करने के लिए यह प्रदर्शन करने के लिए पर्याप्त है rc(O1)-- और rc(On)++. लेवानोनी और पेट्रैंक ने विशिष्ट जावा बेंचमार्क में 99% से अधिक काउंटर अपडेट के उन्मूलन को मापा।
परमाणुता की आवश्यकता है
जब एक थ्रेड (कंप्यूटिंग) वातावरण में उपयोग किया जाता है, तो इन संशोधनों (वृद्धि और कमी) को कम से कम किसी भी ऑब्जेक्ट के लिए तुलना-और-स्वैप जैसे परमाणु संचालन की आवश्यकता हो सकती है, या संभावित रूप से कई थ्रेड्स के बीच साझा किया जाता है। एक मल्टीप्रोसेसर पर परमाणु संचालन महंगे होते हैं, और इससे भी अधिक महंगे होते हैं यदि उन्हें सॉफ्टवेयर एल्गोरिदम के साथ अनुकरण करना पड़ता है। प्रति-थ्रेड या प्रति-सीपीयू संदर्भ गणना जोड़कर और केवल वैश्विक संदर्भ गणना तक पहुंच बनाकर इस समस्या से बचना संभव है, जब स्थानीय संदर्भ संख्या शून्य हो जाती है या शून्य नहीं होती है (या, वैकल्पिक रूप से, संदर्भ गणना के बाइनरी ट्री का उपयोग करके, या यहां तक ​​कि ग्लोबल रेफरेंस काउंट न होने के बदले में नियतात्मक विनाश को छोड़ देना), लेकिन यह महत्वपूर्ण मेमोरी ओवरहेड जोड़ता है और इस तरह केवल विशेष मामलों में उपयोगी होता है (उदाहरण के लिए, लिनक्स कर्नेल मॉड्यूल की संदर्भ गणना में इसका उपयोग किया जाता है) ). लेवानोनी और पेट्रैंक द्वारा समेकन को अद्यतन करें[14][15]राइट-बैरियर से सभी परमाणु संचालन को खत्म करने के लिए इस्तेमाल किया जा सकता है। प्रोग्राम निष्पादन के दौरान प्रोग्राम थ्रेड्स द्वारा काउंटरों को कभी भी अपडेट नहीं किया जाता है। वे केवल संग्राहक द्वारा संशोधित किए जाते हैं जो बिना किसी सिंक्रनाइज़ेशन के एक अतिरिक्त थ्रेड के रूप में निष्पादित होते हैं। इस विधि का उपयोग समांतर कार्यक्रमों के लिए स्टॉप-द-वर्ल्ड तंत्र के रूप में और समवर्ती संदर्भ गिनती कलेक्टर के साथ भी किया जा सकता है।
रीयल-टाइम नहीं
संदर्भ गणना के सरल कार्यान्वयन आम तौर पर रीयल-टाइम व्यवहार प्रदान नहीं करते हैं, क्योंकि कोई भी सूचक असाइनमेंट संभावित रूप से कुल आवंटित स्मृति आकार से बंधे कई ऑब्जेक्ट्स को पुनरावर्ती रूप से मुक्त किया जा सकता है, जबकि थ्रेड अन्य कार्य करने में असमर्थ है . अतिरिक्त ओवरहेड की कीमत पर, अन्य थ्रेड्स के लिए अप्रतिबंधित वस्तुओं को मुक्त करके इस मुद्दे से बचना संभव है।

पलायन विश्लेषण

पलायन विश्लेषण एक कंपाइल-टाइम तकनीक है जो हीप आवंटन को स्टैक आवंटन में बदल सकती है, जिससे कचरा संग्रहण की मात्रा कम हो जाती है। यह विश्लेषण निर्धारित करता है कि किसी फ़ंक्शन के भीतर आवंटित ऑब्जेक्ट इसके बाहर पहुंच योग्य है या नहीं। यदि कोई फ़ंक्शन-स्थानीय आवंटन किसी अन्य फ़ंक्शन या थ्रेड के लिए सुलभ पाया जाता है, तो आवंटन को एस्केप कहा जाता है और स्टैक पर नहीं किया जा सकता है। अन्यथा, ऑब्जेक्ट को सीधे स्टैक पर आवंटित किया जा सकता है और फ़ंक्शन के वापस आने पर ढेर और संबंधित मेमोरी प्रबंधन लागतों को दरकिनार कर जारी किया जा सकता है।[16]


उपलब्धता

सामान्यतया, उच्च-स्तरीय प्रोग्रामिंग भाषा | उच्च-स्तरीय प्रोग्रामिंग भाषाओं में मानक सुविधा के रूप में कचरा संग्रह होने की अधिक संभावना होती है। कुछ भाषाओं में, जिनमें बिल्ट इन गारबेज कलेक्शन नहीं है, इसे लाइब्रेरी के माध्यम से जोड़ा जा सकता है, जैसे कि C और C++ के लिए Boehm गारबेज कलेक्टर के साथ।

अधिकांश कार्यात्मक प्रोग्रामिंग भाषाएं, जैसे एमएल (प्रोग्रामिंग भाषा), हास्केल (प्रोग्रामिंग भाषा), और एपीएल (प्रोग्रामिंग भाषा), में कचरा संग्रह बनाया गया है। लिस्प (प्रोग्रामिंग भाषा) पहली कार्यात्मक प्रोग्रामिंग भाषा और पहली दोनों के रूप में विशेष रूप से उल्लेखनीय है। भाषा कचरा संग्रह शुरू करने के लिए।[17]

अन्य गतिशील भाषाएं, जैसे रूबी (प्रोग्रामिंग भाषा) और जूलिया (प्रोग्रामिंग भाषा) (लेकिन संस्करण 5.3 से पहले पर्ल 5 या PHP नहीं,[18]जो दोनों संदर्भ गिनती का उपयोग करते हैं), [[एकमा स्क्रिप्ट]] और ईसीएमएस्क्रिप्ट भी जीसी का उपयोग करते हैं। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज जैसे स्मॉलटॉक, आरपीएल (प्रोग्रामिंग लैंग्वेज) और जावा (प्रोग्रामिंग लैंग्वेज) आमतौर पर एकीकृत कचरा संग्रह प्रदान करते हैं। उल्लेखनीय अपवाद C++ और डेल्फ़ी (प्रोग्रामिंग भाषा) हैं, जिनमें विध्वंसक (कंप्यूटर विज्ञान) हैं।

बुनियादी

बेसिक और लोगो (प्रोग्रामिंग भाषा) ने अक्सर चर-लंबाई वाले डेटा प्रकारों के लिए कचरा संग्रह का उपयोग किया है, जैसे कि स्ट्रिंग्स और सूचियाँ, ताकि स्मृति प्रबंधन विवरण के साथ प्रोग्रामर को बोझ न किया जा सके। अल्टेयर 8800 पर, कई स्ट्रिंग वेरिएबल्स और छोटे स्ट्रिंग स्पेस वाले प्रोग्राम कचरा संग्रह के कारण लंबे समय तक रोक सकते हैं।[19]इसी तरह Applesoft BASIC दुभाषिया का कचरा संग्रह एल्गोरिदम बार-बार स्ट्रिंग डिस्क्रिप्टर को उच्चतम पते वाले स्ट्रिंग के लिए स्कैन करता है ताकि इसे उच्च मेमोरी की ओर कॉम्पैक्ट किया जा सके, जिसके परिणामस्वरूप बिग ओ नोटेशन |प्रदर्शन[20]और कुछ सेकंड से लेकर कुछ मिनट तक कहीं भी रुक जाता है।[21]रैंडी विगगिंटन द्वारा Applesoft BASIC के लिए एक प्रतिस्थापन कचरा संग्राहक ढेर के ऊपर प्रत्येक पास में स्ट्रिंग्स के एक समूह की पहचान करता है, संग्रह समय को नाटकीय रूप से कम करता है।[22]BASIC.System, 1983 में ProDOS के साथ जारी किया गया, BASIC के लिए एक विंडोिंग कचरा संग्रहकर्ता प्रदान करता है जो कई गुना तेज है।[23]


उद्देश्य-सी

जबकि Objective-C में परंपरागत रूप से कोई कचरा संग्रह नहीं था, 2007 में OS X 10.5 की रिलीज़ के साथ Apple Inc. ने इन-हाउस विकसित रनटाइम कलेक्टर का उपयोग करके Objective-C 2.0 के लिए कचरा संग्रह शुरू किया।[24]हालांकि, 2012 में OS X 10.8 की रिलीज़ के साथ, कचरा संग्रह को LLVM की स्वचालित संदर्भ गणना (ARC) के पक्ष में बहिष्कृत कर दिया गया था जिसे OS X 10.7 के साथ पेश किया गया था।[25]इसके अलावा, मई 2015 से ऐप्पल ने ऐप स्टोर (आईओएस) में नए ओएस एक्स अनुप्रयोगों के लिए कचरा संग्रहण के उपयोग पर भी रोक लगा दी है।[26][27]आईओएस के लिए, आवेदन प्रतिक्रिया और प्रदर्शन में समस्याओं के कारण कचरा संग्रह कभी पेश नहीं किया गया है;[8][28]इसके बजाय, आईओएस एआरसी का उपयोग करता है।[29][30]


सीमित वातावरण

सीमित संसाधनों के उपयोग पर बहुत कड़े नियंत्रण की सामान्य आवश्यकता के कारण कचरा संग्रह का उपयोग शायद ही कभी एम्बेडेड कंप्यूटिंग या रीयल-टाइम सिस्टम पर किया जाता है। हालांकि, कई सीमित वातावरणों के अनुकूल कचरा संग्रहकर्ता विकसित किए गए हैं।[31]Microsoft .NET माइक्रो फ्रेमवर्क, .NET नैनोफ्रेमवर्क[32]और जावा प्लेटफ़ॉर्म, माइक्रो एडिशन एम्बेडेड सॉफ़्टवेयर प्लेटफ़ॉर्म हैं, जिनमें उनके बड़े समकक्षों की तरह कचरा संग्रह शामिल है।

जावा

Java JDKs में उपलब्ध कचरा संग्राहकों में शामिल हैं:

संकलन-समय का उपयोग

संकलन-समय कचरा संग्रह स्थिर कार्यक्रम विश्लेषण का एक रूप है जो स्मृति को पुन: उपयोग करने और संकलन के दौरान ज्ञात इनवेरिएंट के आधार पर पुनः प्राप्त करने की अनुमति देता है।

कचरा संग्रह के इस रूप का बुध (प्रोग्रामिंग भाषा) में अध्ययन किया गया है,[34]और इसने 2011 में Apple के पारिस्थितिकी तंत्र (iOS और OS X) में LLVM की स्वचालित संदर्भ गणना (ARC) की शुरुआत के साथ अधिक उपयोग देखा।[29][30][26]


रीयल-टाइम सिस्टम

उदाहरण के लिए हेनरी बेकर (कंप्यूटर वैज्ञानिक) और हेनरी लिबरमैन द्वारा इंक्रीमेंटल, समवर्ती और रीयल-टाइम कचरा संग्रहकर्ता विकसित किए गए हैं।[35][36][37]

बेकर के एल्गोरिथम में, आवंटन स्मृति के किसी एक क्षेत्र के आधे हिस्से में किया जाता है। जब यह आधा भर जाता है, तो एक कचरा संग्रह किया जाता है जो जीवित वस्तुओं को दूसरे आधे हिस्से में ले जाता है और शेष वस्तुओं को पूरी तरह से अलग कर दिया जाता है। चल रहे प्रोग्राम ('म्यूटेटर') को यह जांचना होगा कि यह संदर्भित कोई भी वस्तु सही आधे हिस्से में है, और यदि इसे पार नहीं किया जाता है, जबकि एक पृष्ठभूमि कार्य सभी वस्तुओं को ढूंढ रहा है।[38]

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

कुछ उच्च-स्तरीय भाषा कंप्यूटर आर्किटेक्चर में रीयल-टाइम कचरा संग्रह के लिए हार्डवेयर समर्थन शामिल है।

रीयल-टाइम कचरा कलेक्टरों के अधिकांश कार्यान्वयन ट्रेसिंग कचरा संग्रह # रीयल-टाइम कचरा संग्रह का उपयोग करते हैं।[citation needed] रीयल-टाइम ऑपरेटिंग सिस्टम के साथ उपयोग किए जाने पर ऐसे रीयल-टाइम कचरा संग्राहक कठिन रीयल-टाइम बाधाओं को पूरा करते हैं।[39]


यह भी देखें

संदर्भ

  1. Abelson, Harold; Sussman, Gerald Jay; Sussman, Julie (2016). Structure and Interpretation of Computer Programs (PDF) (2nd ed.). Cambridge, Massachusetts, USA: MIT Press. pp. 734–736.
  2. McCarthy, John (1960). "Recursive functions of symbolic expressions and their computation by machine, Part I". Communications of the ACM. 3 (4): 184–195. doi:10.1145/367177.367199. S2CID 1489409. Retrieved 2009-05-29.
  3. "What is garbage collection (GC) in programming?". SearchStorage. Retrieved 2022-10-17.
  4. "Overview — D Programming Language". dlang.org. Digital Mars. Retrieved 2014-07-29.
  5. "Garbage Collection - D Programming Language". dlang.org. Retrieved 2022-10-17.
  6. Zorn, Benjamin (1993-01-22). "The Measured Cost of Conservative Garbage Collection". Software: Practice and Experience. Department of Computer Science, University of Colorado Boulder. 23 (7): 733–756. CiteSeerX 10.1.1.14.1816. doi:10.1002/spe.4380230704. S2CID 16182444.
  7. Hertz, Matthew; Berger, Emery D. (2005). "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" (PDF). Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications - OOPSLA '05. p. 313. doi:10.1145/1094811.1094836. ISBN 1-59593031-0. S2CID 6570650. Archived (PDF) from the original on 2012-04-02. Retrieved 2015-03-15.
  8. 8.0 8.1 "Developer Tools Kickoff — session 300" (PDF). WWDC 2011. Apple, Inc. 2011-06-24. Retrieved 2015-03-27.
  9. "Reference Counting Garbage Collection".
  10. "Reference Counts". Extending and Embedding the Python Interpreter. 2008-02-21. Retrieved 2014-05-22.
  11. Ash, Mike. "Friday Q&A 2013-09-27: ARM64 and You". mikeash.com. Retrieved 2014-04-27.
  12. "Hamster Emporium: [objc explain]: Non-pointer isa". Sealiesoftware.com. 2013-09-24. Retrieved 2014-04-27.
  13. Pibinger, Roland (2005-05-03) [2005-04-17]. "RAII, Dynamic Objects, and Factories in C++".
  14. 14.0 14.1 Levanoni, Yossi; Petrank, Erez (2001). "An on-the-fly reference-counting garbage collector for java". Proceedings of the 16th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications. OOPSLA 2001. pp. 367–380. doi:10.1145/504282.504309.
  15. 15.0 15.1 Levanoni, Yossi; Petrank, Erez (2006). "An on-the-fly reference-counting garbage collector for java". ACM Trans. Program. Lang. Syst. 28: 31–69. CiteSeerX 10.1.1.15.9106. doi:10.1145/1111596.1111597. S2CID 14777709.
  16. Salagnac, Guillaume; Yovine, Sergio; Garbervetsky, Diego (2005-05-24). "Fast Escape Analysis for Region-based Memory Management". Electronic Notes in Theoretical Computer Science. 131: 99–110. doi:10.1016/j.entcs.2005.01.026.
  17. Chisnall, David (2011-01-12). Influential Programming Languages, Part 4: Lisp.
  18. "PHP: Performance Considerations". php.net. Retrieved 2015-01-14.
  19. "Altair 8800 Basic 4.1 Reference Manual" (PDF). The Vintage Technology Digital Archive. April 1977. p. 108. Archived (PDF) from the original on 2021-06-29. Retrieved 2021-06-29.
  20. "I did some work to speed up string garbage collection under Applesoft..." Hacker News. Retrieved 2021-06-29.
  21. Little, Gary B. (1985). Inside the Apple IIc. Bowie, Md.: Brady Communications Co. p. 82. ISBN 0-89303-564-5. Retrieved 2021-06-29.
  22. "Fast Garbage Collection". Call-A.P.P.L.E.: 40–45. January 1981.
  23. Worth, Don (1984). Beneath Apple Pro DOS (PDF) (March 1985 printing ed.). Chatsworth, California, USA: Quality Software. pp. 2–6. ISBN 0-912985-05-4. Archived (PDF) from the original on 2008-12-03. Retrieved 2021-06-29.
  24. "Objective-C 2.0 Overview". Archived from the original on 2010-07-24.
  25. Siracusa, John (2011-07-20). "Mac OS X 10.7 Lion: the Ars Technica review".
  26. 26.0 26.1 "Apple says Mac app makers must transition to ARC memory management by May". AppleInsider. 2015-02-20.
  27. Cichon, Waldemar (2015-02-21). "App Store: Apple entfernt Programme mit Garbage Collection". Heise.de. Retrieved 2015-03-30.
  28. Silva, Precious (2014-11-18). "iOS 8 vs Android 5.0 Lollipop: Apple Kills Google with Memory Efficiency". International Business Times. Retrieved 2015-04-07.
  29. 29.0 29.1 Napier, Rob; Kumar, Mugunth (2012-11-20). iOS 6 Programming Pushing the Limit. John Wiley & Sons. ISBN 978-1-11844997-4. Retrieved 2015-03-30.
  30. 30.0 30.1 Cruz, José R. C. (2012-05-22). "Automatic Reference Counting on iOS". Dr. Dobbs. Retrieved 2015-03-30.
  31. Fu, Wei; Hauser, Carl (2005). "A real-time garbage collection framework for embedded systems". Proceedings of the 2005 Workshop on Software and Compilers for Embedded Systems - SCOPES '05. pp. 20–26. doi:10.1145/1140389.1140392. ISBN 1-59593207-0. S2CID 8635481.
  32. ".NET nanoFramework".
  33. Tene, Gil; Iyengar, Balaji; Wolf, Michael (2011). "C4: the continuously concurrent compacting collector" (PDF). ISMM '11: Proceedings of the international symposium on Memory management. doi:10.1145/1993478. ISBN 978-1-45030263-0. Archived (PDF) from the original on 2017-08-09.
  34. Mazur, Nancy (May 2004). Compile-time garbage collection for the declarative language Mercury (PDF) (Thesis). Katholieke Universiteit Leuven. Archived (PDF) from the original on 2014-04-27.
  35. Huelsbergen, Lorenz; Winterbottom, Phil (1998). "Very concurrent mark-&-sweep garbage collection without fine-grain synchronization" (PDF). Proceedings of the First International Symposium on Memory Management - ISMM '98. pp. 166–175. doi:10.1145/286860.286878. ISBN 1-58113114-3. S2CID 14399427. Archived (PDF) from the original on 2008-05-13.
  36. "GC FAQ".
  37. Lieberman, Henry; Hewitt, Carl (1983). "A real-time garbage collector based on the lifetimes of objects". Communications of the ACM. 26 (6): 419–429. doi:10.1145/358141.358147. hdl:1721.1/6335. S2CID 14161480.
  38. Baker, Henry G. (1978). "List processing in real time on a serial computer". Communications of the ACM. 21 (4): 280–294. doi:10.1145/359460.359470. hdl:1721.1/41976. S2CID 17661259. see also description
  39. McCloskey; Bacon; Cheng; Grove (2008), Staccato: A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors (PDF), archived (PDF) from the original on 2014-03-11


अग्रिम पठन


बाहरी संबंध