🌤️ 🈂️ 🦌 सी में लिम्बो के लिए मॉड्यूल का विकास (भाग 2) ✅ 🧤 👴🏼

सामग्री

ढेर

सी में जटिल संरचनाओं को सही ढंग से बनाने और नष्ट करने के लिए कि लिंबो कोड के साथ काम करेगा, आपको यह कल्पना करने की आवश्यकता है कि वे मेमोरी में कैसे संग्रहीत किए जाते हैं, अर्थात्। इनफर्नो में ढेर का आयोजन कैसे किया जाता है। हीप के साथ काम करने के लिए नीचे दिए गए सभी कार्यों को libinterp/heap.c में वर्णित किया गया है, और संरचनाओं में include/interp.h ।

मेरी याद में क्या है ...

केवल ढेर में n बाइट्स का चयन करने और फिर उन्हें मुक्त करने के लिए, आपको निम्नलिखित कार्य करने की आवश्यकता है:

 Heap *h; uchar *data; h = nheap(256); data = H2D(uchar*, h); ... //   data  256  destroy(data);

शारीरिक रूप से, मेमोरी को 256 + ढेर-हेडर बाइट्स का आकार आवंटित किया जाएगा, और शुरुआत में एक हेडर होगा, और फिर उपयोगकर्ता डेटा। हेडर को Heap संरचना में वर्णित किया गया है, साथ ही एक पॉइंटर को एक पॉइडर को डेटा (एक सुविधा के लिए, एक टाइप कास्ट के साथ) के लिए एक हेडर हैडर में परिवर्तित करने के लिए दो मैक्रोज़ हैं, H2D() और इसके विपरीत D2H() । destroy() फ़ंक्शन अज्ञात लंबाई के उपयोगकर्ता डेटा की शुरुआत के लिए एक पॉइंटर के बजाय ढेर हेडर प्राप्त करने के लिए D2H() का उपयोग करता है और पता करता है कि कितने बाइट को मुक्त करने की आवश्यकता है।

 struct Heap { int color; /* Allocation color */ ulong ref; Type* t; ulong hprof; /* heap profiling */ }; #define H2D(t, x) ((t)(((uchar*)(x))+sizeof(Heap))) #define D2H(x) ((Heap*)(((uchar*)(x))-sizeof(Heap)))

कचरा संग्रह के बारे में थोड़ा सा

हीप हेडर में क्या है? मैं आपको hprof बारे में कुछ भी नहीं बताऊंगा, मैं ढेर प्रोफाइलिंग को नहीं समझता था, लेकिन बाकी क्षेत्र बेहद महत्वपूर्ण हैं।

शुरू करने के लिए, इनफर्नो में कचरा कलेक्टर के बारे में कुछ शब्द। दो रणनीतियों का एक साथ उपयोग किया जाता है: एक सरल संदर्भ काउंटर जो अधिकांश संरचनाओं के लिए पर्याप्त है, साथ ही चक्रीय लिंक के साथ संरचनाओं का चयन करने के लिए त्रि-रंग अंकन के विषय पर एक भिन्नता है। तदनुसार, ref एक संदर्भ काउंटर है, और color उपयोग त्रि-रंग अंकन के लिए किया जाता है। जब nheap() या इसी तरह का एक अन्य फ़ंक्शन ढेर करने के लिए एक नई वस्तु आवंटित करता है, तो इसके हीप हेडर में ref मान 1 पर सेट होता है। जब destroy() जाता है destroy() कहा जाता है, तो यह 1 से ref के मूल्य को कम कर देता है, और केवल तभी 0 हो जाता है - कब्जे वाली वस्तु को मुक्त करता है स्मृति।

तदनुसार, जब आप एक चर में nheap() (या किसी अन्य समान फ़ंक्शन) द्वारा लौटाए गए मान को संग्रहीत करते हैं - आपके पास इस ऑब्जेक्ट का ठीक एक संदर्भ होता है, और इसका ref होता है 1. जैसे ही आप इस लिंक को किसी अन्य चर में कॉपी करते हैं - आपको संदर्भ काउंटर को बढ़ाने की आवश्यकता होती है प्लस इसके बारे में त्रि-रंग एल्गोरिथ्म को सूचित करता है। यह इस तरह से किया जाता है ( Setmark() भी एक मैक्रो है, लेकिन इससे निपटने के लिए आपको त्रि-रंग एल्गोरिथ्म के संचालन को समझने की आवश्यकता है, जो आपको अभी आवश्यक नहीं है):

 Heap *h; uchar *data, *data2; data = H2D(uchar*, nheap(256)); data2 = data; h = D2H(data2); h->ref++; Setmark(h); //   h->color destroy(data); //       destroy(data2); //

बेशक, यदि आपने ढेर में एक वस्तु का चयन किया है और फिर इसे *f->ret को लिखकर उपयोगकर्ता को लौटा दिया है, तो आपको ref और color साथ कुछ भी अतिरिक्त करने की आवश्यकता नहीं है - फ़ंक्शन समाप्त होने पर आपके फ़ंक्शन के स्थानीय चर से लिंक हटा दिया जाएगा, और फिर से केवल एक उपयोगकर्ता के पास इस ऑब्जेक्ट के लिए एक लिंक है, चर में जहां उसने आपके फ़ंक्शन द्वारा लौटाए गए मूल्य को बचाया, अर्थात। एक चाल थी, लिंक की एक प्रति नहीं।

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

 dst->data = src->data; src->data = H; Setmark(D2H(dst->data));

ढेर में वस्तु प्रकार

ऊपर वर्णित nheap() उदाहरण लगभग वास्तविक कोड में कभी उपयोग नहीं किया गया है, जैसा कि लिम्बो में यह डेटा प्रकार नहीं है: n बाइट्स। इसलिए, न तो लिम्बो से प्राप्त करें और न ही लिम्बो पर लौटें। और अपने सी-मॉड्यूल की आंतरिक जरूरतों के लिए स्मृति आवंटित करने के लिए, एक नियम के रूप में, free() साथ पर्याप्त साधारण malloc() free() ।

ढेर में सभी वस्तुएं जिनके साथ लिंबो संचालित कर सकते हैं, Type संरचना द्वारा वर्णित कुछ प्रकार के होने चाहिए। यह हमें किसी भी वस्तु के अंदर सभी लिंक की स्वचालित पहचान की समस्या को हल करने की अनुमति देता है - इसके साथ क्या किया जाना चाहिए:

इस ऑब्जेक्ट के लिए मेमोरी आवंटित करना (इसके अंदर सभी बिंदुओं को H उर्फ nil );
destroy() (ताकि जब इसके साथ एक मेमोरी को ऑब्जेक्ट हटा दिया जाए, तो सभी ऑब्जेक्ट्स के लिए ref को हटा दें या कम करें, जिसे इसे संदर्भित किया गया है);
कचरा संग्रहकर्ता का कार्य (उन वस्तुओं को ध्यान में रखना जो स्मृति में सभी वस्तुओं को ट्रेस करते समय अन्य जटिल वस्तुओं के अंदर संदर्भित होते हैं)।

 struct Type { int ref; void (*free)(Heap*, int); void (*mark)(Type*, void*); int size; int np; void* destroy; void* initialize; uchar map[STRUCTALIGN]; };

मानक प्रकारों के लिए (कोई भी adt / tuple / संरचना जिसमें या तो गैर-संदर्भ फ़ील्ड या साधारण हीप ऑब्जेक्ट्स के लिंक वाले फ़ील्ड होते हैं जिन्हें destroy() माध्यम से मुक्त किया जा सकता है destroy() - जैसे String* और Array* ) np और map फ़ील्ड का उपयोग किया जाता है। map फ़ील्ड में adt / tuple / संरचना के प्रत्येक 4 बाइट्स के लिए एक बिट मास्क, एक बिट (पहले बाइट के सबसे महत्वपूर्ण बिट के साथ शुरू) होता है, जहां सेट बिट का अर्थ है कि संबंधित 4 बाइट्स एक हंटर ऑब्जेक्ट के लिए एक पॉइंटर है। ( np फ़ील्ड में बाइट्स में map फ़ील्ड की लंबाई शामिल है।)

कुछ डेटा प्रकार एक बहुत मानक तरीके से मेमोरी का उपयोग नहीं करते हैं। विशिष्ट उदाहरण String और Array - पहले में char* फ़ील्ड शामिल है, जिसे free() माध्यम से free() किया जाना चाहिए; दूसरा एक टुकड़ा हो सकता है और अपने आप में "माता-पिता" सरणी का लिंक हो सकता है। Type संरचना आपको इन प्रकारों के लिए गैर-मानक हैंडलर फ़ंक्शंस निर्दिष्ट करने की अनुमति देती है, जिन्हें तब कहा जाएगा जब मेमोरी आवंटित की जाती है / प्रारंभ की जाती है, destroy() और कचरा कलेक्टर से: free : free , mark , destroy और initialize ।

size फ़ील्ड में इस प्रकार की संरचना का आकार होता है (चूंकि हम सभी समान हैं, इस संरचना के लिए मेमोरी आवंटित करते समय इसके प्रकार को इंगित करने के लिए मजबूर किया जाता है, प्रकार के अंदर संरचना के आकार को सहेजकर हमें केवल प्रकार को निर्दिष्ट करने के लिए खुद को सीमित करने की अनुमति देता है, प्रत्येक बार संरचना के आकार को जोड़े बिना)।

ref फील्ड का उपयोग इस प्रकार के ढेर में वस्तुओं की वर्तमान संख्या को स्टोर करने के लिए किया जाता है। तथ्य यह है कि प्रकारों की सूची मानक string , array of , आदि तक सीमित नहीं है। - मक्खी पर वर्णित किसी भी प्रकार का एक अलग प्रकार है जिसके लिए आपको Type संरचना के साथ अपने स्वयं के विवरण की आवश्यकता होती है। यह पता चलता है कि लिम्बो द्वारा कुछ प्रकारों को मक्खी पर बनाया जाता है, उसी ढेर में संग्रहीत किया जाता है, और जैसे ही इस प्रकार की सभी वस्तुओं को हटा दिया जाता है, स्मृति से हटा दिया जाना चाहिए। इसलिए, जब किसी प्रकार की नई वस्तु बनाते हैं, तो इस प्रकार के लिए ref को बढ़ाना आवश्यक होता है, और जब आप इस ऑब्जेक्ट को हटाते हैं, तो destroy() इस प्रकार के ऑब्जेक्ट के रूप में उसी तरह से ref को कम कर देगा (और यदि मेमोरी 0 हो जाती है तो इसे हटा दें)।

मानक प्रकारों के Type मानों को वैधानिक रूप से घोषित किया जाता है, ref सेट 1 के साथ (इसलिए उनका ref कभी भी 1 से कम नहीं होगा और वे मेमोरी से कभी डिलीट नहीं होंगे), और libinterp/head.c की शुरुआत में वर्णित हैं:

 Type Tbyte = { 1, 0, 0, 1 }; Type Tword = { 1, 0, 0, sizeof(WORD) }; Type Tptr = { 1, 0, markheap, sizeof(WORD*), 1, 0, 0, { 0x80 } }; Type Tarray = { 1, freearray, markarray, sizeof(Array) }; Type Tstring = { 1, freestring, noptrs, sizeof(String) }; ...

ढेर में अपनी जटिल संरचनाएं बनाएं

आपके स्वयं के adt / tuples / संरचनाओं के प्रकार कुछ मामलों में libinterp/runt.h द्वारा निर्धारित किए जा सकते हैं ( libinterp/runt.h के लिए आपकी संरचना के आकार की गणना Type.size और Type.map और Type.np लिए सूचक फ़ील्ड के बिटमास्क), दूसरों में आपको उन्हें परिभाषित करना होगा। अपने आप (उदाहरण के लिए, C फ़ंक्शन से टपल बनाने और वापस करने के लिए)। वे आमतौर पर तब बनाए जाते हैं जब आप अपने मॉड्यूल (उदाहरण के लिए, उदाहरण के मॉड्यूल के साथ लौटते हुए) को dtype() फ़ंक्शन का उपयोग करके dtype() करते हैं। और मेमोरी को उनके लिए आवंटित किया गया है और heap(&Tsometype) माध्यम से शुरू किया गया है, और nheap(n_bytes) ।

module/example.m

 Example: module { ... MyData: adt{ i: int; s: string; new: fn(i: int): ref MyData; }; };

libinterp/runt.h ( module/example.m से स्वचालित रूप से उत्पन्न)

 typedef struct Example_MyData Example_MyData; struct Example_MyData { WORD i; String* s; }; #define Example_MyData_size 8 #define Example_MyData_map {0x40,} void MyData_new(void*); typedef struct F_MyData_new F_MyData_new; struct F_MyData_new { WORD regs[NREG-1]; Example_MyData** ret; uchar temps[12]; WORD i; };

मान Example_MyData_map 0x40 का अर्थ है बिट मास्क 010000 ..., अर्थात। हमारी संरचना के पहले 4 बाइट्स एक पॉइंटर (WORD) नहीं हैं, लेकिन दूसरा एक पॉइंटर (स्ट्रिंग *) है।

libinterp/example.c

 static Type* TMyData; static uchar MyData_map[] = Example_MyData_map; void examplemodinit(void) { ... TMyData = dtype(freeheap, Example_MyData_size, MyData_map, sizeof(MyData_map)); } void MyData_new(void *fp) { F_MyData_new *f; int i; Example_MyData* mydata; f = fp; i = f->i; mydata = H2D(Example_MyData*, heap(TMyData)); mydata->i = i; destroy(*f->ret); *f->ret = mydata; }

testexample.b

 ... example: Example; MyData: import example; ... init(nil: ref Draw->Context, nil: list of string) { ... mydata := MyData.new(5); sys->print("i = %d, s = %q\n", mydata.i, mydata.s); } ; testexample ... i = 5, s = '' ;

सरणी

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

 struct Array { WORD len; Type* t; Array* root; uchar* data; };

यहाँ len सरणी का आकार है, t इसके तत्वों का प्रकार है, root पेरेंट सरणी के लिए root पॉइंटर है (यदि यह सरणी इसका टुकड़ा है), और data एरे के पहले तत्व का सूचक है (यह Array बाद अगला Array है यदि सरणी स्वतंत्र है या तत्वों के बीच हमारे स्लाइस के पहले तत्व का पता है) जनक सरणी)।

यदि हम किसी अन्य सरणी का एक टुकड़ा नहीं बनाते हैं, तो हमें खुद Array संरचना से अधिक मेमोरी आवंटित करने की आवश्यकता है (और, तदनुसार, Tarray.size में निर्दिष्ट)। इसलिए, हम पहले उपयोग किए गए heap() फ़ंक्शन के माध्यम से सरणी के लिए मेमोरी आवंटित नहीं कर पाएंगे। सौभाग्य से, इसके लिए एक सुविधाजनक heaparray() फ़ंक्शन है। आवंटन array[16] of byte का एक उदाहरण array[16] of byte :

 Array *arr; arr = H2D(Array*, heaparray(&Tbyte, 16));

यहाँ एक फ़ंक्शन का एक उदाहरण है जो एक सरणी टुकड़ा देता है: http://code.google.com/p/inferno-cjson/source/browse/libinterp/cjson.c#59 ।

adt और रेफरी adt

कैसे adt और रेफरी में संभाला जाता है लिम्बो और सी के बीच एक अंतर्निहित अंतर है। यदि लिम्बो स्तर पर, उनके साथ काम करना (लगभग) समान दिखता है:

 a := array[10] of MyData; b := array[10] of ref MyData; for(i := 0; i < len b; i++) b[i] = ref MyData; a[0].i = b[0].i;

तब C स्तर पर ये पूरी तरह से अलग सरणियाँ हैं:

 Array *a, *b; int i; Example_MyData* adata; Example_MyData** bdata; a = H2D(Array*, heaparray(TMyData, 10)); adata = (Example_MyData*)a->data; b = H2D(Array*, heaparray(&Tptr, 10)); bdata = (Example_MyData**)b->data; for(i = 0; i < b->len; i++) bdata[i] = H2D(Example_MyData*, heap(TMyData)); adata[0].i = bdata[0]->i;

जीसी

विकिपीडिया पर त्रि-रंग एल्गोरिथ्म का एक सामान्य विवरण पाया जा सकता है। इन्फर्नो में, इन तीन "रंगों" को mutator , marker और sweeper कहा जाता है।

नई वस्तुएं h->color=mutator सेट h->color=mutator ।

प्रत्येक पूर्ण जीसी चक्र के बाद, mutator , marker और sweeper चर के मान एक सर्कल में बदलते हैं, इस प्रकार ढेर में सभी वस्तुओं के h->color मूल्यों को बदलते हैं:

 mutator -> marker marker -> sweeper sweeper -> mutator //    ..  sweeper

यदि ऑपरेशन के दौरान जीसी h->color==sweeper , तो h मेमोरी से हटा दिया जाता है।

तो Setmark() क्या है और इसकी आवश्यकता क्यों है।

 #define Setmark(h) if((h)->color!=mutator) { (h)->color = propagator; nprop=1; }

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

यह तंत्र Setmark() लिए कॉल है। यदि आवश्यक हो, तो उसके nprop फ्लैग GC को इंगित करता है कि ढेर में ट्रैवर्सल के मौजूदा चक्र के अंत में अप्रयुक्त वस्तुओं को हटाना असंभव है, लेकिन शुरुआत से चक्र को दोहराना आवश्यक है।

मान h->color==propagator मतलब है कि अगली बार जब आप जीसी चलाते हैं, तो आपको इस ऑब्जेक्ट को देखने की आवश्यकता है। किसी वस्तु को देखने पर h->color mutator सेट mutator । (एक ही propagator मूल्य एक नए जीसी चक्र की शुरुआत में "रूट" ऑब्जेक्ट्स पर सेट है, लेकिन यह इस संदर्भ में नहीं है।)

जीसी से ढेर में एक वस्तु को डिस्कनेक्ट करना

चूंकि जीसी मेमोरी से उन सभी वस्तुओं को हटाता है जो "रूट" ऑब्जेक्ट्स से संदर्भित नहीं हैं (जिसमें संभवतः काम करने वाले डिस्क थ्रेड्स, लोड किए गए मॉड्यूल आदि शामिल हैं), उनके ref मूल्य की परवाह किए बिना, सवाल उठता है: कैसे एक ढेर ऑब्जेक्ट के लिए एक लिंक स्टोर करने के लिए बाहर डिस थ्रेड्स, उदाहरण के लिए आपके सी-मॉड्यूल के वैश्विक चर में, ताकि जीसी इसे न मारें? ऐसा करने के लिए, जीसी को सूचित करना आवश्यक है कि यह जीसी को वापस जोड़ने के लिए poolimmutable() (वहाँ poolimmutable() का उपयोग करके इस हीप ऑब्जेक्ट को नियंत्रित नहीं करना चाहिए, ये सभी कार्य emu/port/alloc.c :