स्टैक-आधारित मेमोरी आवंटन

स्टैक (अमूर्त डेटा प्रकार) #Hardware_stacks कंप्यूटिंग आर्किटेक्चर में मेमोरी (कंप्यूटर) के क्षेत्र हैं जहां डेटा को LIFO (कंप्यूटिंग) | लास्ट-इन-फर्स्ट-आउट (LIFO) तरीके से जोड़ा या हटाया जाता है।

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

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

फायदे और नुकसान
क्योंकि डेटा को लास्ट-इन-फर्स्ट-आउट तरीके से जोड़ा और हटाया जाता है, स्टैक-आधारित मेमोरी एलोकेशन बहुत सरल है और आमतौर पर हीप-आधारित मेमोरी एलोकेशन (गतिशील स्मृति आवंटन के रूप में भी जाना जाता है) की तुलना में बहुत तेज़ है। सी (प्रोग्रामिंग भाषा) । malloc.

एक अन्य विशेषता यह है कि स्टैक पर मेमोरी स्वचालित रूप से और बहुत कुशलता से, फ़ंक्शन से बाहर निकलने पर पुनः प्राप्त होती है, जो प्रोग्रामर के लिए सुविधाजनक हो सकती है यदि डेटा की आवश्यकता नहीं है। (यही बात setjmp.h पर भी लागू होती है अगर यह कॉल करने से पहले एक बिंदु पर चली जाती है alloca हुआ।) हालांकि, यदि डेटा को किसी रूप में रखने की आवश्यकता है, तो फ़ंक्शन से बाहर निकलने से पहले इसे स्टैक से हीप में कॉपी किया जाना चाहिए। इसलिए, स्टैक आधारित आवंटन अस्थायी डेटा या डेटा के लिए उपयुक्त है जो वर्तमान फ़ंक्शन के बाहर निकलने के बाद आवश्यक नहीं है।

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

स्टैक-आधारित आवंटन मामूली प्रदर्शन समस्याएं भी पैदा कर सकता है: यह चर-आकार के स्टैक फ़्रेमों की ओर जाता है, ताकि दोनों कॉल स्टैक#STACK-POINTER को प्रबंधित करने की आवश्यकता हो (निश्चित आकार के स्टैक फ़्रेमों के साथ, स्टैक पॉइंटर बेमानी है क्योंकि ढेर फ्रेम सूचक प्रत्येक फ्रेम के आकार से)। यह आमतौर पर कॉल करने की तुलना में बहुत कम खर्चीला होता है malloc और free फिर भी। विशेष रूप से, यदि वर्तमान फ़ंक्शन में एलोका और चर-लंबाई वाले स्थानीय डेटा वाले ब्लॉक दोनों कॉल शामिल हैं, तो वर्तमान स्टैक फ्रेम को बढ़ाने के लिए एलोका के प्रयासों के बीच एक संघर्ष होता है, जब तक कि वर्तमान फ़ंक्शन बाहर नहीं निकलता है बनाम संकलक की चर लंबाई के स्थानीय चर को रखने की आवश्यकता होती है। ढेर फ्रेम में एक ही स्थान। एलोका को प्रत्येक कॉल के लिए ढेर भंडारण की एक अलग श्रृंखला बनाकर इस विरोध को आम तौर पर हल किया जाता है। श्रृंखला स्टैक की गहराई को रिकॉर्ड करती है जिस पर प्रत्येक आवंटन होता है, बाद में किसी भी फ़ंक्शन में एलोका को कॉल करता है, इस श्रृंखला को वर्तमान स्टैक गहराई तक ट्रिम कर देता है ताकि अंततः (लेकिन तुरंत नहीं) इस श्रृंखला पर कोई भंडारण मुक्त हो सके। शून्य के तर्क के साथ एलोका को कॉल करने के लिए भी ऐसी मेमोरी आवंटित किए बिना स्मृति को मुक्त करने के लिए उपयोग किया जा सकता है। एलोका और स्थानीय चर भंडारण के बीच इस संघर्ष के परिणामस्वरूप, एलोका का उपयोग करना मॉलोक का उपयोग करने से अधिक कुशल नहीं हो सकता है।

सिस्टम इंटरफ़ेस
कई यूनिक्स-जैसी प्रणालियाँ और साथ ही माइक्रोसॉफ़्ट विंडोज़ ़ नामक एक कार्य को लागू करते हैं alloca हीप-आधारित के समान स्टैक मेमोरी को गतिशील रूप से आवंटित करने के लिए. एक कंपाइलर आमतौर पर इसे स्टैक पॉइंटर में हेरफेर करने वाले इनलाइन निर्देशों में अनुवाद करता है, जैसा कि चर-लंबाई सरणी को हैंडल किया जाता है। हालाँकि मेमोरी को स्पष्ट रूप से मुक्त करने की कोई आवश्यकता नहीं है, स्टैक ओवरफ़्लो के कारण अपरिभाषित व्यवहार का जोखिम है। यह कार्य UNIX/32V|32/V (1978) से ही यूनिक्स सिस्टम पर मौजूद था, लेकिन यह मानक C या किसी POSIX मानक का हिस्सा नहीं है।

का एक सुरक्षित संस्करण alloca बुलाया _malloca, जो त्रुटियों की रिपोर्ट करता है, Microsoft Windows पर मौजूद है। इसके उपयोग की आवश्यकता है _freea. gnulib समतुल्य इंटरफ़ेस प्रदान करता है, हालांकि अतिप्रवाह पर एसईएच अपवाद फेंकने के बजाय, यह प्रतिनिधि करता है malloc जब बड़े आकार का पता चलता है। इसी तरह की सुविधा को मैन्युअल लेखा और आकार-जांच का उपयोग करके अनुकरण किया जा सकता है, जैसे कि उपयोग में alloca_account ग्लिब में। कुछ प्रोसेसर परिवारों, जैसे कि x86, के पास वर्तमान में निष्पादित थ्रेड के ढेर में हेरफेर करने के लिए विशेष निर्देश हैं। PowerPC और MIPS आर्किटेक्चर सहित अन्य प्रोसेसर परिवारों के पास स्पष्ट स्टैक समर्थन नहीं है, बल्कि इसके बजाय सम्मेलन पर भरोसा करते हैं और ऑपरेटिंग सिस्टम के अनुप्रयोग बाइनरी इंटरफ़ेस (ABI) को स्टैक प्रबंधन सौंपते हैं।

ऑटो वीएलए
इसके अलावा, C संस्करण C99 (C11 के बाद से वैकल्पिक) के बाद से, एक फ़ंक्शन के भीतर स्टैक पर एक सरणी बनाना संभव है, स्वचालित रूप से, एक ऑटो VLA (चर-लंबाई सरणी) के रूप में जाना जाता है।

यह भी देखें

 * स्वचालित चर
 * स्थैतिक चर
 * कॉल स्टैक
 * गतिशील स्मृति आवंटन
 * ढेर बफर अतिप्रवाह
 * स्टैक मशीन
 * स्टैक ओवरफ़्लो