एक गैर-प्रयोगात्मक कचरा संग्रह एल्गोरिदम है जो वास्तव में आपकी सभी आवश्यकताओं को पूरा करता है: सरल स्वचालित refcounting। पूरी तरह से, वास्तव में एक व्यवहार्य विकल्प के रूप में पर्याप्त क्रेडिट प्राप्त नहीं होता है, लेकिन असल में यह कई स्थितियों में वास्तव में अच्छी तरह से काम करता है, कभी भी कोई बड़ी बैच देरी नहीं होती है, और जटिल जादू की कोई आवश्यकता नहीं होती है।
एक चिंता अभी भी परिपत्र संदर्भों की सफाई कर रही है, जिसे आप कम से कम शायद ही कभी किया जा सकता है; एप डेवलपर्स जो गति की परवाह करते हैं, वे स्पष्ट रूप से लूप को तोड़ सकते हैं जब उन्हें दूर जाने के लिए वस्तुओं की आवश्यकता होती है।
refcounting की एक छोटी सराहना की विशेषता यह है कि यह कचरा संग्रह के अन्य रूपों की तुलना में अधिक dcache- अनुकूल है।यदि आप एक लूप चला रहे हैं जो लूप के माध्यम से हर बार कुछ छोटी अस्थायी वस्तुओं को आवंटित करता है, तो एक refcounting जीसी (या स्पष्ट स्मृति प्रबंधन, निश्चित रूप से) हर बार एक ही स्मृति का पुन: उपयोग कर सकते हैं, अनावश्यक कैश फ्लश से परहेज। किसी अन्य प्रकार का जीसी समय-समय पर वस्तुओं को मुक्त कर देगा, जिसके परिणामस्वरूप एक बड़ी स्मृति पदचिह्न और इसलिए धीमा हो जाएगा।
रेफकाउंटिंग भारी बहु थ्रेडेड सिस्टम के लिए बहुत प्रभावी नहीं है, क्योंकि हर बार जब आप रिफॉउंट को स्पर्श करते हैं तो आपको ताले हासिल करने की आवश्यकता होती है। लेकिन अगर आप किसी भी तरह की नई भाषा तैयार कर रहे हैं, तो अपनी सारी भाषा में प्रदर्शन और विश्वसनीयता में सुधार करने के लिए आप एक बड़ी चीज कर सकते हैं: लगभग सभी वस्तुओं को थ्रेड के बीच साझा करने से रोकें। अर्थात। स्पष्ट साझा करना। यदि आप ऐसा करते हैं, तो आप जान लेंगे कि कौन सी ऑब्जेक्ट बनाम साझा नहीं की जाती हैं, और इसलिए रिफॉउंट को बढ़ाने/घटाने के दौरान जिन्हें लॉक किया जाना चाहिए और जिन्हें अनलॉक किया जा सकता है। जब कोई लॉकिंग नहीं होती है, तो प्रदर्शन को पुन: गणना करना वास्तव में उत्कृष्ट हो सकता है।
आप नेट को लक्षित या जावा मंच आप मुक्त करने के लिए एक हो जाएगा। –
यहां एक हास्यास्पद रूप से अच्छा [लेखों की श्रृंखला] है (http://blogs.msdn.com/b/abhinaba/archive/2009/01/25/back-to-basic-series-on-dynamic-memory-management.aspx) कचरा संग्रह पर। – jason
@ हेनक, वह एक कंपाइलर लिख रहा है – ThomasMcLeod