कुछ समय पहले हमने सार्वजनिक रिलीज की घोषणा की और Mua लाइसेंस के तहत खोला LuaVela का स्रोत कोड - Lua 5.1 का कार्यान्वयन, LuaJIT 2.0 पर आधारित है। हमने 2015 में इस पर काम करना शुरू किया, और 2017 की शुरुआत तक कंपनी के 95% से अधिक प्रोजेक्ट्स में इसका इस्तेमाल किया गया। अब मैं यात्रा के मार्ग पर वापस देखना चाहता हूं। किन परिस्थितियों ने हमें एक प्रोग्रामिंग भाषा के अपने कार्यान्वयन को विकसित करने के लिए प्रेरित किया? हमने किन समस्याओं का सामना किया और हमने उन्हें कैसे हल किया? कैसे LuaVela अन्य LuaJIT कांटे से अलग है?

प्रागितिहास

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

समय के साथ, हमने महसूस किया कि LuaJIT वास्तुकला की कुछ सीमाएँ थीं। हमारे लिए सबसे महत्वपूर्ण बात यह थी कि LuaJIT 2.0 सख्ती से 32-बिट पॉइंटर्स का उपयोग करता है। इससे हमें एक ऐसी स्थिति में ले जाया गया, जहां 64-बिट लिनक्स पर चलने से प्रक्रिया मेमोरी के वर्चुअल एड्रेस स्पेस का आकार एक गीगाबाइट तक सीमित हो जाता है (लिनक्स कर्नेल के बाद के संस्करणों में, यह सीमा दो गीगाबाइट तक बढ़ गई थी):

/* MAP_32BIT    4  x86-64: */ void *ptr = mmap((void *)MMAP_REGION_START, size, MMAP_PROT, MAP_32BIT | MMAP_FLAGS, -1, 0); 

यह सीमा एक बड़ी समस्या बन गई - 2015 तक, 1-2 गीगाबाइट मेमोरी बंद हो गई, जो कि कई प्रोजेक्ट्स के लिए पर्याप्त थी जो लॉजिक ने काम किया था। यह ध्यान देने योग्य है कि लुआ आभासी मशीन का प्रत्येक उदाहरण एकल-थ्रेडेड है और यह नहीं जानता कि अन्य उदाहरणों के साथ डेटा कैसे साझा किया जाए - इसका मतलब है कि प्रत्येक वर्चुअल मशीन एक मेमोरी साइज 2GB / n से अधिक नहीं होने का दावा कर सकती है, जहां n हमारे सर्वर के कार्य प्रवाह की संख्या है अनुप्रयोगों।

हम समस्या के कई समाधानों से गुजरे: हमने अपने एप्लिकेशन सर्वर में थ्रेड्स की संख्या कम कर दी, LuaJIT FFI के माध्यम से डेटा तक पहुंच को व्यवस्थित करने की कोशिश की, LuaJIT 2.1 के लिए संक्रमण का परीक्षण किया। दुर्भाग्य से, इन विकल्पों में से सभी या तो आर्थिक रूप से नुकसानदेह थे या लंबे समय में अच्छी तरह से पैमाने पर नहीं थे। हमारे लिए केवल एक चीज बची हुई थी कि हम एक मौका लें और LuaJIT को कांटे। इस समय, हमने ऐसे निर्णय लिए जो मोटे तौर पर परियोजना के भाग्य को निर्धारित करते हैं।

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

इसके अलावा, हमने हमारे केवल उत्पादन प्लेटफॉर्म लिनक्स x86-64 का समर्थन करने के पक्ष में क्रॉस-प्लेटफॉर्म को छोड़ दिया। दुर्भाग्य से, हमारे पास पर्याप्त मात्रा में परिवर्तनों का परीक्षण करने के लिए पर्याप्त संसाधन नहीं थे जो हम मंच पर करने जा रहे थे।

मंच के हुड के नीचे एक त्वरित नज़र

आइए देखें कि संकेत के आकार पर प्रतिबंध कहां से आता है। के साथ शुरू करने के लिए, लुआ 5.1 में संख्या प्रकार (कुछ मामूली कैविट्स के साथ) सी प्रकार डबल है, जो बदले में IEEE 754 मानक द्वारा परिभाषित डबल परिशुद्धता प्रकार से मेल खाती है। इस 64-बिट प्रकार के एन्कोडिंग में, मानों की श्रेणी प्रस्तुति के लिए हाइलाइट की गई है। NaN। विशेष रूप से, सीमा में कोई मान [0xFFF8000000000000; 0xFFFFFFFFFFFFFFFF]।

इस प्रकार, हम एक एकल 64-बिट मूल्य में एक "वास्तविक" डबल-सटीक संख्या, या कुछ इकाई को पैक कर सकते हैं, जो कि टाइप डबल के दृष्टिकोण से NaN के रूप में व्याख्या की जाएगी, और हमारे मंच के दृष्टिकोण से यह कुछ सार्थक होगा - उदाहरण के लिए, ऑब्जेक्ट के प्रकार (उच्च 32 बिट्स) और इसकी सामग्री के लिए एक सूचक (कम 32 बिट्स):

 union TValue { double n; struct object { void *payload; uint32_t type; } o; }; 

इस तकनीक को कभी-कभी NaN टैगिंग (या NaN बॉक्सिंग) कहा जाता है, और TValue मूल रूप से बताता है कि LuaJIT कैसे Lua में चर मानों का प्रतिनिधित्व करता है। TValue में एक तीसरे हाइपोस्टैसिस का उपयोग किया जाता है जो एक फ़ंक्शन और जानकारी को Lua स्टैक को रिवाइंड करने के लिए उपयोग करता है, यानी अंतिम विश्लेषण में, डेटा संरचना इस तरह दिखती है:

 union TValue { double n; struct object { void *payload; uint32_t type; } o; struct frame { void *func; uintptr_t link; } f; }; 

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

आइए एक उदाहरण देखें। कल्पना करें कि हमने LuaJIT के साथ इस Lua कोड की शुरुआत की और प्रिंट फ़ंक्शन के अंदर एक विराम बिंदु सेट किया:

 local function foo(x) print("Hello, " .. x) end local function bar(a, b) local n = math.pi foo(b) end bar({}, "Lua") 

इस बिंदु पर Lua स्टैक इस तरह दिखेगा:



और सब कुछ ठीक होगा, लेकिन जैसे ही हम x86-64 पर शुरू करने की कोशिश करते हैं, यह तकनीक विफल होने लगती है। यदि हम 32-बिट अनुप्रयोगों के लिए संगतता मोड में चलते हैं, तो हम ऊपर उल्लिखित एमएमएपी प्रतिबंध के खिलाफ आराम करते हैं। और 64-बिट पॉइंटर्स बॉक्स से बाहर काम नहीं करेंगे। क्या करें? मेरे पास जो समस्या थी उसे ठीक करने के लिए:

1. TValue को 64 से 128 बिट्स तक बढ़ाएं: इस तरह हमें 64-बिट प्लेटफॉर्म पर "ईमानदार" शून्य मिलता है।
2. तदनुसार वर्चुअल मशीन कोड को ठीक करें।
3. जेआईटी कंपाइलर में बदलाव करें।

परिवर्तनों की कुल मात्रा बहुत महत्वपूर्ण हो गई और हमें मूल LuaJIT से अलग कर दिया गया। यह ध्यान देने योग्य है कि TValue एक्सटेंशन समस्या को हल करने का एकमात्र तरीका नहीं है। LuaJIT 2.1 में, हम LJ_GC64 मोड को लागू करके दूसरे रास्ते पर चले गए। पीटर कावली, जिन्होंने ऑपरेशन के इस तरीके के विकास में बहुत बड़ा योगदान दिया, लंदन में एक बैठक में इसके बारे में पढ़ा। लुवावेला के मामले में, एक ही उदाहरण के लिए स्टैक इस तरह दिखता है:

पहली सफलताओं और परियोजना का स्थिरीकरण

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

उसी समय, परीक्षण का सवाल खड़ा हुआ। सौभाग्य से, हमें स्क्रैच से शुरू नहीं करना था, क्योंकि विकास के पहले दिन से, मचान सर्वर के अलावा, हमारे पास हमारे पास था:

• एक एप्लिकेशन सर्वर के कार्यात्मक और एकीकरण परीक्षण जो सभी कंपनी परियोजनाओं के व्यापार तर्क को निष्पादित करते हैं।
• व्यक्तिगत परियोजनाओं के परीक्षण।

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

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

अंत में, हमने लुओ इकोसिस्टम में सबसे पूर्ण और प्रतिनिधि परीक्षण सूट को एकीकृत करके हमारे परीक्षण में बंद कर दिया:

• भाषा के रचनाकारों द्वारा लुआ 5.1 के कार्यान्वयन के लिए लिखे गए परीक्षण ।
• LuaJIT लेखक माइक पाल द्वारा समुदाय द्वारा प्रदान किए गए टेस्ट ।
• लुआ हार्नेस
• सर्न द्वारा विकसित की जा रही एमएडी परियोजना के परीक्षणों का एक सबसेट।
• IPONWEB में हमारे द्वारा बनाए गए परीक्षणों के दो सेट और अब तक फिर से भरना जारी है: एक प्लेटफ़ॉर्म के कार्यात्मक परीक्षण के लिए, दूसरा C API के परीक्षण के लिए cmocka फ्रेमवर्क का उपयोग करने वाला और वह सब जिसमें Lua कोड स्तर पर परीक्षण का अभाव है।

परीक्षणों के प्रत्येक बैच की शुरूआत ने हमें 2-3 महत्वपूर्ण त्रुटियों का पता लगाने और सही करने की अनुमति दी - इसलिए यह स्पष्ट है कि हमारे प्रयासों ने भुगतान किया। और यद्यपि भाषा रनटाइम्स और कंपाइलर्स (स्थैतिक और गतिशील दोनों) के परीक्षण का विषय वास्तव में असीम है, हम मानते हैं कि हमने परियोजना के स्थिर विकास के लिए ठोस आधार दिया है। हमने मास्को के 2017 में और हाईलोअड ++ 2018 में लुआ में दो बार लुआ के हमारे अपने कार्यान्वयन (परीक्षण बेंच और पोस्टमॉर्टम डिबगिंग के साथ काम करने वाले विषयों सहित) की समस्याओं के बारे में बात की थी। खैर, हमारी रिपॉजिटरी में परीक्षण निर्देशिका को देखें, निश्चित रूप से।

नई सुविधाएँ

इस प्रकार, हमने अपने निपटान में लिनक्स x86-64 के लिए Lua 5.1 का एक स्थिर कार्यान्वयन किया था, जिसे एक छोटी टीम की शक्तियों द्वारा विकसित किया गया था जो धीरे-धीरे LuaJIT विरासत और संचित विशेषज्ञता को "महारत हासिल" करता था। ऐसी स्थितियों में, प्लेटफ़ॉर्म का विस्तार करने और न तो वेनिला लुआ में और न ही लुजिट में ऐसी विशेषताओं को जोड़ने की इच्छा, लेकिन जो हमें अन्य दबाने वाली समस्याओं को हल करने में मदद करेगी, काफी स्वाभाविक हो गई।

सभी एक्सटेंशनों का विस्तृत विवरण आरएसटी प्रारूप में प्रलेखन में दिया गया है (एचटीएमएल प्रारूप में स्थानीय प्रतिलिपि बनाने के लिए cmake। && डॉक्स बनाते हैं)। इस लिंक पर Lua API एक्सटेंशन का पूरा विवरण और इस पर C API पाया जा सकता है। दुर्भाग्य से, एक समीक्षा लेख में सब कुछ के बारे में बात करना असंभव है, इसलिए यहां सबसे महत्वपूर्ण कार्यों की एक सूची है:

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

इन विशेषताओं में से प्रत्येक एक अलग लेख के हकदार हैं - उन टिप्पणियों में लिखें जिनके बारे में आप अधिक पढ़ना चाहते हैं।

यहां मैं थोड़ा और बात करना चाहता हूं कि हमने कचरा कलेक्टर पर भार कैसे कम किया। सील आपको कचरा कलेक्टर के लिए दुर्गम बनाने के लिए अनुमति देता है। हमारे विशिष्ट प्रोजेक्ट में, Lua वर्चुअल मशीन के अंदर अधिकांश डेटा (80% तक) पहले से ही व्यावसायिक नियम हैं, जो एक जटिल दुआ तालिका है। इस तालिका (मिनट) का जीवनकाल संसाधित अनुरोधों (मिलीसेकंड के दसियों) के जीवनकाल से बहुत लंबा है, और इसमें डेटा क्वेरी प्रसंस्करण के दौरान नहीं बदलता है। ऐसी स्थिति में, कचरे के संग्रहकर्ता को बार-बार इस विशाल डेटा संरचना के आसपास फिर से इकट्ठा करने के लिए मजबूर करने का कोई मतलब नहीं है। ऐसा करने के लिए, हम ऑब्जेक्ट को पुन: "सील" करते हैं और डेटा को इस तरह से पुन: व्यवस्थित करते हैं कि कचरा कलेक्टर कभी भी "सील" ऑब्जेक्ट या उसकी सामग्री तक नहीं पहुंचता है। वेनिला लुआ 5.4 में, इस समस्या को पीढ़ीगत कचरा संग्रह में वस्तुओं का समर्थन करके हल किया जाएगा।

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

मैं यह भी ध्यान देता हूं कि लुआ 5.1 में मेटाटैबल्स का उपयोग करके प्रतिरक्षा को लागू किया जा सकता है - समाधान काफी काम कर रहा है, लेकिन प्रदर्शन के मामले में सबसे अधिक लाभदायक नहीं है। "सीलिंग," प्रतिरक्षा पर अधिक जानकारी, और हम रोजमर्रा की जिंदगी में उनका उपयोग कैसे करते हैं, इस रिपोर्ट में पाया जा सकता है।

निष्कर्ष

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

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

आपका ध्यान के लिए धन्यवाद, हम पुल अनुरोधों की प्रतीक्षा कर रहे हैं!