2012-03-29 11 views
61

मेरे एप्लिकेशन को एक ही (सिंगल-थ्रेडेड) प्रक्रिया में कई अलग-अलग संदर्भ चलाने की आवश्यकता है। वे सभी एक LLVMContext साझा करते हैं।डिज़ाइन सुझाव: llvm एकाधिक रनटाइम संदर्भ

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

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

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

मेरे प्रारंभिक आवेग, प्रत्येक संदर्भ के लिए एक llvm::Module संबद्ध करने के लिए गया था, लेकिन क्या संकलन का एक मध्यवर्ती राज्य में एक मॉड्यूल के साथ होता है LLVM में अपनी अपरिभाषित के बाद से, मैं प्रत्येक अनुवाद इकाई (this question for the reason देखें) के लिए एक llvm::Module जोड़ने का निर्णय लिया प्लस कॉपी-ऑन-राइट पॉलिसी मैंने पहले समझाया था कि किसी अन्य संदर्भ को प्रभावित करने वाले संशोधन से बचने के लिए, अनुवाद इकाई के संशोधन स्थानीय रूप से संदर्भ में होते हैं।

मुख्य दो गुना सवाल मैंने किया है:

  • मैं कैसे एक साथ विभिन्न मॉड्यूल एक संदर्भ में, ताकि उन्हें एक एकीकृत पुस्तकालय के रूप में आह्वान करने के लिए में लिंक करूं? मैं सी ++ एपीआई का उपयोग कर रहा हूँ। मैं इस कार्यक्षमता को प्रभावित करने वाले this nasty, old bug से विशेष रूप से सावधान हूं। क्या यह बग अभी भी मुझे प्रभावित करेगा यदि मैंने ExecutionEngine::addModule() के साथ जेआईटी में सभी मॉड्यूल के स्वामित्व को स्थानांतरित कर दिया है?

  • अनुवाद इकाई पर संशोधन के बाद आवश्यक कदम क्या हैं मॉड्यूल में से किसी एक के अद्यतन को मजबूर करता है? क्या मुझे पुरानी मॉड्यूल ऑब्जेक्ट को छोड़ने/हटाने और एक नया निर्माण करने की आवश्यकता है? क्या एक रीसाइक्लिंग नीति है जिसके बारे में मैंने नहीं पढ़ा है?

एक माध्यमिक सवाल मैं इस बारे में है:

  • मैं कितने ExecutionEngine की ज़रूरत है? एक पूरे आवेदन के लिए? प्रति संदर्भ एक? एक प्रति मॉड्यूल?

आशा है कि प्रश्न का दायरा बहुत जबरदस्त नहीं है।

+2

मैं एक विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि मैं कम से कम शुरू करने के लिए यहां कुछ जोड़ सकता हूं। 1 ए पर सवाल करने के लिए: [आपके लिंक] के नीचे (http://llvm.org/bugs/show_bug.cgi?id=2606) सकारात्मक लगता है कि जेआईटी में आपके मॉड्यूल फेंकना वास्तव में बग के आसपास काम करेगा। 1 बी तक: [एपीआई दस्तावेज़] (http://llvm.org/docs/doxygen/html/classllvm_1_1Module.html) कोई संसाधन रीसाइक्लिंग का सुझाव नहीं देता है, केवल एक [पास संरचना] (http://llvm.org/docs/WritingAnLLVMPass .html)। तो, यह आपके मॉड्यूल के उत्परिवर्तन पर निर्भर करता है। 2: मैं कहता हूं, अपने डिजाइन और जरूरतों को निर्धारित करने दें कि, आपके पहले दो प्रश्नों के समाधान दिए गए हैं। सौभाग्य! – MrGomez

+0

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

उत्तर

1

मुझे लगता है कि आपको अपने विचारों को "लटका" देने के लिए एक वैचारिक ढांचे की आवश्यकता है। कमांडिंग के रूप में विभिन्न निष्पादन बिट्स (शायद कमांड पैटर्न का उपयोग करके कार्यान्वित करने) के बारे में सोचने से आप इंटरैक्शन पॉइंट्स का एक और स्पष्ट सेट देंगे। ऐसा कहे जाने के बाद; आपको प्रत्येक असतत निष्पादन के लिए एक संदर्भ की आवश्यकता होगी जिसे आप वापस करना चाहते हैं। दो से अधिक की आवश्यकता होगी कि आप उचित पुस्तक रखने के लिए तैयार हों। मेरा मानना ​​है कि दो को बढ़ावा देने के लिए अनिवार्य रूप से संभाला जाता है।
निष्पादन बिट्स के बीच संचार समान रूप से आपके ऊपर है। निष्पादन संदर्भों में साझा किया गया एक राज्य (स्मृति) बनाना एक ऐसा समाधान है जो दिमाग में आता है। आपके पास पहले से ही आपके रन टाइम में उपयुक्त राज्य हो सकता है, फिर कोई अतिरिक्त परत की आवश्यकता नहीं होगी। जैसा कि आपने बताया कि ग्लोबल्स इन इंटरैक्शन में आपका मित्र नहीं हैं। संस्करण और नाम समाधान भी एक मुद्दा है। निष्पादन बिट्स को अलग रखना इस समस्या को हल करने के लिए एक लंबा रास्ता तय करता है। एक बार जब आप समन्वय मुद्दे को हल कर लेते हैं तो यह ट्रैक करने की बात है कि आप पहले से बनाए गए बिट्स को ट्रैक कर रहे हैं। इसका मतलब यह भी है कि रीसाइक्लिंग की कोई आवश्यकता नहीं है, बस हर बार नया बनाएं और कोई रीलोड नहीं है। निष्पादन पूरा करने के बाद आपको इन बिट्स के जीवन का अंत भी प्रबंधित करना होगा। मैं प्रति निष्पादन बिट ExecutionEngine का प्रस्ताव दे रहा हूं। ऐसा करने के लिए, गलत कोड के प्रभाव से काम करने वाले कोड को "सुरक्षित" करने का प्रयास करने का एक और अधिक काम है। मेरा मानना ​​है कि यह एक इंजन के साथ ऐसा करना संभव है, लेकिन यह काफी जोखिम भरा होगा।

संबंधित मुद्दे