Design: टैग की गईं जीसी पॉइंटर्स

आप इसे पहले से ही लीनियर मेमोरी में कर सकते हैं, बस उपयोग करने से पहले पॉइंटर को मास्क करें। मैं इस उपयोग के मामले पर विचार करने के लिए वर्षों से संघर्ष कर रहा हूं, और समर्थन का उपयोग कर सकता हूं, और मेरे पास एक योजना है।

@sebmarkbage क्या आपके पास

टैग के लिए: क्या आपके पास वीएम आपको "टैग के एन बिट्स उपलब्ध" संपत्ति देगा और आपके ऊपर कुछ भी स्वयं को संभालेगा, या यदि आप अनिर्दिष्ट सीमा से अधिक हो तो ऑटो-जादुई रूप से साइड-स्टोरेज का उपयोग करें?

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

@jfbastien मुझे अभी तक यकीन नहीं है कि नियंत्रण में रहना बेहतर होगा या इसे बनाया गया है। अब मुझे यह भी लगता है कि कुछ मामलों में टैग किए गए पॉइंटर्स की तुलना में ऑब्जेक्ट हेडर टैग का उपयोग करना बेहतर हो सकता है। आम तौर पर मुझे एक लेखक के रूप में नियंत्रण में रहना पसंद है लेकिन इस मामले में आपको प्रत्येक शाखा के लिए बहुत सारे अतिरिक्त कोड भेजने पड़ सकते हैं, इसलिए मुझे लगता है कि मैं स्वचालित रूप से साइड-स्टोरेज का उपयोग करने की ओर झुक रहा हूं।

मुझे एनम प्रस्ताव ऑनलाइन नहीं मिल रहा है। यह मूल्य प्रकारों का हिस्सा था लेकिन मुझे लगता है कि हम इसे मूल्य प्रकारों से अलग कर सकते हैं। सीसी @littledan

@ रॉसबर्ग-क्रोमियम मेरा मतलब टैग किए गए पॉइंटर्स से था लेकिन अब जब आप इसका जिक्र करते हैं, तो मैं देख सकता हूं कि ऑब्जेक्ट हेडर में टैग वी 8 जैसे कुछ डिज़ाइनों में कैसे उपयोगी हो सकते हैं। मैं देख सकता था कि प्लेटफॉर्म के आधार पर एक या दूसरे को चुनना उपयोगी है। वास्तव में पेचीदा।

@ रॉसबर्ग-क्रोमियम क्या आप अधिक विशिष्ट हो सकते हैं जब आप "हम" शब्द का उपयोग भविष्य में "हम इसके बारे में सोच रहे हैं" के रूप में करते हैं। जहां तक ​​मेरी जानकारी है, इस समुदाय समूह द्वारा इस मामले पर कोई विचार नहीं किया गया है और मैं नहीं चाहता कि इस समुदाय समूह के कार्य को गलत तरीके से प्रस्तुत किया जाए। उदाहरण के लिए आप इसे भविष्य में 'द वी8 टीम' कहना चाहेंगे या सदस्यता देने वाले उपसमूह के लिए एक नाम बनाना चाहेंगे। यदि अध्यक्षों ने एक निजी प्रवचन को जारी रखने की अनुमति दी है जिसने सदस्यों को सूचित और नियंत्रण में रखे बिना इस समूह के काम की दिशा को प्रेरित किया है तो क्या वे कृपया अपना अध्यक्ष वापस कर सकते हैं। यदि अध्यक्षों का चुनाव सदस्यों द्वारा नहीं किया जाता है तो क्या वे कृपया अपनी पीठें वापस कर सकते हैं।

मैं टैग किए गए पॉइंटर्स को इस तरह से आगे बढ़ाने का सुझाव दूंगा जो मूल्य प्रकारों या टाइप की गई वस्तुओं से अलग हो। उदाहरण के लिए, आप यहां 2-4 टैग बिट्स तक सीमित रखना चाह सकते हैं, जबकि जावास्क्रिप्ट में जोड़े गए एडीटी को इस तरह का प्रतिबंध नहीं लगाना चाहिए। सीसी @tschneidereit

जब @ रॉसबर्ग-क्रोमियम "हम" के बारे में बात करता है तो उसका मतलब WASM पर काम करने वाले लोगों के बीच अनौपचारिक सेटिंग्स में होता है। यह देखते हुए कि मैं उससे 3 मीटर दूर बैठता हूं, ऐसा लगता है कि इस संचार को आशीर्वाद देने के लिए विशिष्ट उपसमूह स्थापित करने के लिए बहुत अधिक ओवरहेड है :-)

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

@titzer संयोग से, "हम" (@ lars-t-hansen, I और कुछ अन्य wasm लोग) किसी प्रकार की प्रतिबंधित राशि के समान मूल विचार पर चर्चा कर रहे थे जो हमेशा एक टैग-शब्द प्रतिनिधित्व की अनुमति देता था।

इस गर्मी में एक बातचीत से क्या हुआ, यह विचार था कि एक डिजाइन में जहां जीसी-सक्षम वस्तुओं का एक अलग ढेर होता है (टाइप्डऑब्जेक्ट्स, शायद) दो नए वास प्रकार हो सकते हैं:

एक "सूचक" जीसी-सक्षम ढेर में कुछ gc'd चीज़ के लिए एक अपारदर्शी संदर्भ (शायद शून्य) है। यह Wasm-32 पर 4 बाइट्स और Wasm-64 पर 8 बाइट्स है।

एक "बॉक्स" एक सूचक आकार का ट्रिपल है:

• पॉइंटर डिज़ाइनर बिट (1 बिट)
• टैग बिट्स (2 या 3 बिट्स, शब्दों के आकार पर निर्भर हो सकते हैं)
• मान (एक सूचक यदि सूचक सूचक सेट है, अन्यथा एक पूर्णांक)

कुछ प्रशंसनीय संचालन:
Boxptr (सूचक, टैग) -> बॉक्स [1, टैग, सूचक]
बॉक्सवाल (पूर्णांक, टैग) -> बॉक्स [0, टैग, पूर्णांक और ~ 15]
ptrbitof(बॉक्स) -> 0 या 1
टैगोफ़ (बॉक्स) -> टैग
ptof(Box) -> पॉइंटर या नल यदि बॉक्स पॉइंटर बॉक्स नहीं है
valof(Box) -> पूर्णांक मान या 0 यदि बॉक्स पूर्णांक बॉक्स नहीं है

वर्तमान प्रकारों के अलावा wasm में स्थानीय और वैश्विक चर बॉक्स-टाइप या पीटीआर-टाइप किए गए होंगे। रेखीय ढेर में पॉइंटर्स और बॉक्स संग्रहणीय नहीं होते हैं।

मैंने जो स्केच किया है वह कम से कम कई गतिशील भाषाओं के लिए उपयुक्त और प्रदर्शनकारी होना चाहिए; व्यवहार में, 3 टैग बिट्स (पॉइंटर बिट प्लस टू बिट्स) आमतौर पर ठीक है, उसके बाद वस्तुओं में अतिरिक्त टैग बिट्स संग्रहीत किए जा सकते हैं। पॉइंटर डिज़ाइनर और टैग बिट्स को वर्ड के लो बिट में स्टोर किया जाता है।

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

@ लार्स-टी-हैनसेन मुझे लगता है कि टाइप टेस्ट ऑपरेटरों की आवश्यकता है ताकि कोड if(is_int(p)) ... फहरा सके और फिर संकलक को पता चल जाएगा कि p को एक पूर्णांक के रूप में टैग किया गया है न कि एक सूचक और अनुकूलित कर सकता है valof() संकलक के बिना उत्थापन करने के लिए। मुझे ptrof() की आवश्यकता नहीं दिखती क्योंकि रनटाइम को वैसे भी उपयोग पर प्रकार की जांच करने की आवश्यकता होती है और एक पूर्णांक परीक्षण के लिए एक और प्रकार है।

टैगिंग को 'मुक्केबाजी' कहने के बारे में निश्चित नहीं है, क्योंकि 'मुक्केबाजी' का अर्थ अक्सर एक ढेर बॉक्स में आवंटित करना होता है।

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

@wllang , हाँ, मैंने टाइप टेस्ट गारंटी होगी या नहीं। is_int(x) eqz(ptrbitof(x)) के बराबर है जो शुरुआत के लिए पहचानने के लिए बहुत कठिन पैटर्न नहीं है; is_ptr(x) सिर्फ ptrbitof(x) है। चूंकि यह एक स्टैक मशीन है, इसलिए एक काल्पनिक एक-बाइट ऑपरेशन "i32.isint" और दो-बाइट ऑपरेशन के बीच वास्तव में एक महीन रेखा होती है, जिसमें दो यूनरी सिंगल-बाइट वाले होते हैं, "i32.ptrbit; i32.eqz"।

लेकिन सटीक रूप मायने नहीं रखता, क्या मायने रखता है प्रभाव। यह स्पष्ट प्रतीत होता है कि "if(is_ptr(x)) {...} और {...}" के भीतर संकलक मान सकता है कि x तत्कालीन ब्लॉक में एक सूचक है और अन्य ब्लॉक में एक पूर्णांक है, यदि यह मूल्य साबित कर सकता है परीक्षण में x के लिए उन ब्लॉकों के भीतर x की तुल्यता। यह एसएसए-आधारित प्रणाली के लिए कठिन नहीं लगता। लेकिन क्या आपको उन ब्लॉकों के भीतर एक टैग जांच को छोड़ने की आवश्यकता होगी ?

मान लीजिए कि हम एक बाइटकोड को दो मानों में परिणाम देने की अनुमति देते हैं; सिंटैक्स का दुरुपयोग करते हुए, एक ऑपरेशन ptr_i32.ptof एक पॉइंटर (या नल) और एक बूलियन लौटाएगा। फिर इस बारे में कोई सवाल नहीं होगा कि संकलक को "जानना" क्या होगा, इसका केवल एक मूल्य होगा जो निर्माण द्वारा सूचक है। (इन टाइप की गई वस्तुओं के लिए एक प्रकार की प्रणाली का भी सवाल है और किस अर्थ में पॉइंटर्स टाइप किए गए हैं, लेकिन मुझे लगता है कि यह शायद टैगिंग के लिए ऑर्थोगोनल है।)

(थोड़ा पीछे हटते हुए, इस बारे में अतिरिक्त दिलचस्प विचार हैं कि क्या कुछ सरल टैग वाले संभावित-इंट बॉक्स पर अंकगणित और बिटवाइज़ संचालन की अनुमति दी जानी चाहिए, कुछ प्रकार के स्टेटस कोड रिटर्न के साथ, SPARC पर टैग किए गए निर्देशों की तुलना में। i32x2.add k, a, b का परिणाम (a+b, 0) होगा यदि a और b दोनों निचले k टैग बिट्स == 0 के साथ int बॉक्स हैं और कोई अतिप्रवाह नहीं है, अन्यथा (कचरा, 1)। i32x2.or k, a, b ditto a|b। इन कार्यों को वासम स्तर पर कुशलता से व्यक्त करना कठिन है लेकिन हार्डवेयर स्तर पर लागू करना आसान है। लेकिन यह संभव है कि ये इसके लायक होने के लिए बहुत विशिष्ट हैं - ऐसा मामला बनाना होगा कि इसे लक्षित करना दिलचस्प हो लिस्पिश भाषाएँ to wasm।)

जहां तक ​​हाई एड्रेस बिट्स का सवाल है... मुझे नहीं पता कि आपने इसके बारे में पहले क्या लिखा है। क्या आप किसी प्रकार की BiBoP योजना लागू करना चाहते हैं या आप टैग के लिए उच्च बिट्स का उपयोग करना चाहते हैं?

(आप जिस मोज़िला बग का उल्लेख कर रहे हैं उसका संदर्भ?)

मामला बनाना होगा कि लिस्पिश भाषाओं को wasm . पर लक्षित करना दिलचस्प है

यदि आपको लगता है कि WebAssembly को सभी प्रोग्रामिंग भाषाओं को प्रभावी ढंग से समर्थन देने का प्रयास नहीं करना चाहिए, तो मुझे लगता है कि आप Wasm के महत्व को कम करके आंक रहे हैं। सही किया, वासम पूरी दुनिया पर कब्जा कर लेगा। Wasm ऑपरेटिंग सिस्टम, CPU आर्किटेक्चर और (मुझे आशा है) प्रोग्रामिंग भाषाओं की लॉक-इन पावर कम कर देगा। ऑफ़लाइन और ऑनलाइन ऐप्स के लिए, और क्लाइंट और सर्वर के लिए समान रूप से, हर कोई इसका उपयोग करने जा रहा है।

वह दुनिया ऐसी नहीं होनी चाहिए जिसमें कुछ प्रोग्रामिंग तकनीकें और प्रोग्रामिंग भाषाएं हों और वे अक्षम और अव्यवहारिक हों क्योंकि WebAssembly डिजाइनरों ने सोचा था कि वे भाषाएं समर्थन के लिए पर्याप्त "महत्वपूर्ण" नहीं थीं। बहुत सी चीजें जिन्हें हम अभी मानते हैं, साथ ही नई भाषाओं की विशेषताएं, अस्पष्ट शैक्षणिक भाषाओं और/या लिस्प में शुरू हुई हैं।

हमारा लक्ष्य सभी भाषाओं और सभी प्रोग्रामिंग तकनीकों को अच्छे प्रदर्शन के साथ समर्थन करना होना चाहिए, जैसे कि किसी तकनीक के इष्टतम कार्यान्वयन के लिए हमेशा 2x मेमोरी और सीपीयू समय के भीतर। शुरुआत के लिए, एक उच्च-प्रदर्शन वाले Wasm कार्यान्वयन एक और उच्च-प्रदर्शन Wasm कार्यान्वयन या उसके अंदर चल रहे JVM या CLR को कुशलतापूर्वक होस्ट करने में सक्षम होना चाहिए (जो सभी कोड जनरेशन के लिए बाहरी Wasm इंजन का लाभ उठाएंगे), या एक Lisp VM या a स्टैकलेस पायथन। इन सब से परे, मैं निरंतरता (या कम से कम किसी प्रकार का माइक्रोथ्रेड सिस्टम) देखना चाहता हूं, एक फ़ंक्शन के भीतर फास्ट गोटो के लिए "प्रथम श्रेणी" लेबल ... ठीक है, मूल रूप से भविष्य की सुविधाओं में सब कुछ और फिर कुछ। जबकि काम को प्राथमिकता देनी होती है, यह नहीं भूलना चाहिए कि यह सब महत्वपूर्ण है।

@ lars-t-hansen मुझे GC/अपारदर्शी ढेर (साथ ही अन्य सभी के विचारों) के लिए आपके डिज़ाइन विचारों की बेहतर समझ प्राप्त करना अच्छा लगेगा। WebAssembly VM के संबंध में टैग बिट्स का क्या प्रभाव होगा?

हम "सभी उद्देश्य" VM कैसे बनाते हैं? कुछ है कि

• सटीक, संकुचित, पीढ़ीगत जीसी का समर्थन करता है
• सरणी स्लाइस और पॉइंटर्स का समर्थन करता है जो किसी वस्तु या सरणी के मध्य को संदर्भित करता है, न कि केवल शुरुआत
• "पतले" और "वसा" पॉइंटर्स - या दोनों के आधार पर ऑब्जेक्ट सिस्टम का समर्थन करता है! (पतले पॉइंटर्स इंगित की गई वस्तु में संग्रहीत प्रकार की जानकारी पर भरोसा करते हैं, जबकि वसा पॉइंटर्स उस जानकारी को एक अतिरिक्त शब्द या पॉइंटर के साथ दो में संग्रहीत करते हैं)
• "शायद पॉइंटर्स" की अनुमति देता है जो गतिशील रूप से पॉइंटर्स और पूर्णांक के बीच स्विच कर सकता है
• संघ प्रकारों का कुशलतापूर्वक समर्थन करता है (ए या बी या सी के सूचक - यह उनमें से एक होना चाहिए, लेकिन कौन सा गतिशील है)
• हमारी सुरक्षा बाधाओं के तहत जहां तक ​​संभव हो, स्मृति आवंटन और जीसी पर क्लाइंट नियंत्रण की अनुमति देता है।
• अपारदर्शी संदर्भों का समर्थन करता है - भले ही यह "ड्राइवर की सीट" में Wasm क्लाइंट कोड डालने के सामान्य लक्ष्य के साथ तनाव में प्रतीत होता है, जैसे क्लाइंट को अपना स्वयं का GC एल्गोरिदम करने देना
• अन्य सामान का समर्थन करता है जिसके बारे में मैंने सोचा भी नहीं है

इसमें अस्वीकरण कि यह टिप्पणी ओपी में इस मुद्दे के लिए विशेष नहीं है।

यदि आपको लगता है कि WebAssembly को सभी प्रोग्रामिंग भाषाओं को प्रभावी ढंग से समर्थन देने का प्रयास नहीं करना चाहिए, तो मुझे लगता है कि आप Wasm के महत्व को कम करके आंक रहे हैं। सही किया, वासम पूरी दुनिया पर कब्जा कर लेगा....

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

मुझे व्यक्तिगत रूप से नहीं लगता कि WebAssembly के पास इन व्यापक अनुप्रयोगों को पूरा करने के लिए साधन नहीं है; मैं व्यक्तिगत रूप से गैर-ब्राउज़र-उन्मुख इंटरनेट-आधारित आभासी अनुप्रयोगों की अवधारणाओं के परिप्रेक्ष्य से WASM में रुचि रखता हूं, जिन्हें वेब ब्राउज़िंग की वास्तविकता को प्रकाशित करने वाले दस्तावेज़ के अनुलग्नक के बिना, html और css की तरह सुरक्षित रूप से साझा और आनंद लिया जा सकता है। विशेष रूप से, मुझे नहीं लगता कि WebAssembly के मुख्य दायित्व इसे पूरी तरह से चर्चा से हटा देते हैं जो एक ISA की संभावना को आगे बढ़ाता है जो इन सभी प्रकार की संभावनाओं को पूरा करता है, चाहे वह ISA आपके दिए गए समस्या डोमेन के लिए WebAssembly हो या नहीं।

मुझे नहीं लगता कि "टेक ओवर द वर्ल्ड" शूट करने के लिए एक महान लक्ष्य है

बस मेरी भविष्यवाणी। मैं यह नहीं कह रहा हूं कि दुनिया पर कब्जा करना लक्ष्य है - मैं कह रहा हूं कि WebAssembly विशिष्ट रूप से स्थित है, जैसे कि एक अच्छा मौका है कि यह दुनिया पर कब्जा कर लेगा बिना किसी विशेष रूप से ऐसा करने की कोशिश कर रहा है।

तो, WebAssembly VM के संबंध में टैग बिट्स का क्या प्रभाव होगा? ये किसलिए हैं?

मैंने ऊपर से अपनी टिप्पणियां निकालीं और थोड़ा विस्तृत किया, ताकि हमारे पास हर बार इस पूरे धागे को स्कैन किए बिना विचारों को विकसित होते देखने के लिए एक जगह हो:
https://github.com/lars-t-hansen/moz-sandbox/blob/master/wasm-tagging.md

उस राइटअप में "क्यों टैगिंग" के लिए तर्क भी थोड़ा अधिक है? और सुरक्षा, पूर्व कला, आदि पर कुछ टिप्पणियाँ।

@qwertie , मैं

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

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

टैगिंग चर्चा एक तरह से आकर्षक है क्योंकि अब तक, बाड़ के हमारे पक्ष में चर्चा कुछ ऐसी चीज लेने के बारे में रही है जो हमारे पास होनी चाहिए (एक अपारदर्शी ढेर में संकेत) और एक सस्ती सुविधा जोड़ना

मैं असहमत हूं कि एक अपारदर्शी ढेर में पॉइंटर्स ऐसी सुविधा है जो WebAssembly के पास होनी चाहिए। मैं गतिशील और GCed भाषाओं के लिए WebAssembly के समर्थन के लिए तीन संभावित दिशाओं के बारे में सोच सकता हूं:

1. केवल गैर-जीसीड स्थिर भाषाओं के लिए एक अच्छा वीएम होने की चिंता करें।
2. एक जेएस-इंटर-ऑपरेटेबल टाइप और कचरा एकत्रित ढेर का पर्दाफाश करें।
3. WebAssembly में गतिशील रूप से टाइप की गई भाषाओं (या स्थिर रूप से टाइप की गई GCed भाषाओं) को लागू करने के लिए आवश्यक आदिम को उजागर करें: जैसे JIT कोड पैचिंग, लीनियर मेमोरी इकट्ठा करने वाले कचरे के लिए स्टैक वॉकिंग, आदि।

एमवीपी ने एमवीपी के बाद इसे प्रतिबद्ध किए बिना अपने दायरे को पहली दिशा तक सीमित कर दिया है।

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

हालांकि, मेरा मानना ​​है कि तीसरी दिशा WebAssembly के लिए सबसे अच्छी दीर्घकालिक दिशा है। दूसरी दिशा WebAssembly से ब्राउज़र DOM के साथ काम करना आसान बनाकर प्रेरित लगती है। हालांकि, कोई भी सीधे WebAssembly में कोड नहीं लिख रहा होगा, इसलिए कुछ भाषा समर्थन आवश्यक होगा, और यह DOM तक पहुँचने के लिए प्रक्रियात्मक JS API का उपयोग उतनी ही प्रभावी ढंग से कर सकता है जैसे कि DOM के लिए निम्न-स्तरीय पहुँच थी।

दूसरी दिशा JVM/.net, या योजना, या रूबी के लिए WASM बैकएंड को जावास्क्रिप्ट कचरा संग्रहकर्ता का पुन: उपयोग करने की अनुमति देगी। हालांकि, कचरा संग्रहकर्ता एक आकार-फिट-सभी नहीं हैं: संभावित परिणाम WASM VMs के लिए एक टाइप + GCed ढेर को शामिल करने के लिए एक स्थायी आवश्यकता पेश कर रहा है जो कई अनुप्रयोगों की प्रदर्शन आवश्यकताओं को पूरा नहीं करेगा।

तीसरी दिशा में अधिक काम करने की आवश्यकता है, लेकिन लंबी अवधि में दोनों को सरल स्टैंडअलोन WASM VMs की अनुमति देनी चाहिए और ब्राउज़र VMs की जटिलता को कम करना चाहिए क्योंकि आज के अधिक वीर अनुकूलन प्रयास JavaScript VMs से WASM सैंडबॉक्स में माइग्रेट होते हैं।

मैंने पहले एक कचरा संग्रहकर्ता को लागू करने के लिए जावास्क्रिप्ट जीसी ढेर को WebAssembly बनाम उजागर करने वाले प्राइमेटिव्स को उजागर करने की सापेक्ष प्राथमिकता पर चर्चा करने के लिए # 733 बनाया था। शायद WASM GC की दिशा के बारे में आगे की चर्चा वहाँ जारी रह सकती है, और यह मुद्दा इस धारणा के साथ टैग किए गए GC पॉइंटर्स पर केंद्रित रह सकता है कि GC हीप में अपारदर्शी पॉइंटर्स के लिए WASM में समर्थन जोड़ा जाएगा।

@ लार्स-टी-हैनसेन आपके राइटअप में यह उल्लेख नहीं है कि यह कचरा संग्रह से कैसे संबंधित है, या अपारदर्शी संदर्भों के लिए स्मृति क्षेत्र के विचार से संबंधित है। क्या कोई अंतर्निहित धारणा है कि अपारदर्शी संदर्भ "ढेर" या "तालिका" "बक्से" (या उह ... "टैग किए गए पीटीआरएस" ... टीपी?) की एक साधारण सरणी होगी, जैसे कि इनमें से कोई भी बॉक्स संदर्भित कर सकता है एक JS ऑब्जेक्ट, जिसे इस प्रकार JS GC द्वारा जीवित रखा जाएगा?

दस्तावेज़ को देखने के बाद, मेरे साथ ऐसा होता है कि हो सकता है कि आपका विचार यह नहीं है कि WebAssembly Wasm की ओर से कचरा इकट्ठा करता है - लेकिन केवल अपारदर्शी संदर्भ क्षेत्र को JS ऑब्जेक्ट्स के दोनों संदर्भों को रखने की अनुमति देता है (उन्हें एकत्र होने से रोकने के लिए) और अन्य सामान, जैसे पूर्णांक और स्वयं के आंतरिक संदर्भ। एक (अविश्वसनीय) जीसी तब WebAssembly के लिए बनाया जा सकता है जो अपारदर्शी संदर्भ क्षेत्र का समर्थन करने के लिए होता है।

क्या मैं गर्म हो रहा हूँ?

प्रथम श्रेणी निरंतरता के बारे में - यह एक विशेषता है कि मुझे यकीन नहीं है कि हमें इसकी आवश्यकता है। Coroutines या हल्के ढेर, निश्चित, लेकिन निरंतरता? क्या कोई वास्तव में उन्हें किसी अन्य प्रकार के फाइबर/कोरआउटिन/थ्रेड चीज़ बनाने के अलावा किसी अन्य चीज़ के लिए उपयोग करता है जो ढेर के संग्रह के रूप में व्यवहार करता है? हो सकता है कि स्विच-स्टैक ऑपोड के साथ किसी प्रकार की "लाइटवेट" स्टैक चीज़ का समर्थन करना पर्याप्त हो। उस स्थिति में call/cc WebAssembly के तहत उपलब्ध नहीं होगा, लेकिन लोग call/cc जो चीजें बनाने की प्रवृत्ति रखते हैं, वे होंगी।

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

• मुझे इंटरऑपरेबिलिटी की बहुत परवाह है; बिल्ट-इन गारबेज कलेक्टर होने से विभिन्न कचरा-एकत्रित भाषाओं के लिए इंटरऑपरेट करना आसान हो सकता है।
• कचरा संग्रहकर्ता सॉफ्टवेयर के बड़े टुकड़े हो सकते हैं, और प्रत्येक वेब साइट से एक अलग जीसी डाउनलोड करना भारी हो सकता है

तो मुझे लगता है कि मैं कुछ प्रकार का डिफ़ॉल्ट जीसी होना चाहता हूं, लेकिन वासम में एक कस्टम जीसी को लागू करने से डिफ़ॉल्ट का उपयोग करने पर कोई बड़ा नकारात्मक पक्ष नहीं होना चाहिए।

@AndrewScheidecker , उचित बिंदु - यह नहीं दिया गया है कि हमारे पास gc'd ढेर में अपारदर्शी पॉइंटर्स होना चाहिए। मेरा सुझाव है कि हम उस चर्चा को अंक #733 में जारी रखें जैसा कि आप प्रस्तावित करते हैं। पारित होने में, हालांकि, मुझे लगता है कि आपका दावा है कि "तीसरी दिशा [...] लंबी अवधि में दोनों को सरल स्टैंडअलोन WASM VMs की अनुमति देनी चाहिए और ब्राउज़र VMs की जटिलता को कम करना चाहिए क्योंकि आज के अधिक वीर अनुकूलन प्रयास JavaScript VMs से माइग्रेट होते हैं WASM सैंडबॉक्स में।" इसके समर्थन में तर्क और कोड दोनों की आवश्यकता है; यह स्पष्ट नहीं है कि यह सच है।

@qwertie , यहाँ मेरी सामान्य धारणा यह है कि वहाँ wasm स्थानीय और शायद Ptr और Box प्रकार के ग्लोबल्स होंगे; कि अपारदर्शी वस्तुओं में ऐसे क्षेत्र हो सकते हैं जिन्हें स्थिर रूप से Ptr या Box के रूप में टाइप किया जाएगा; और यह कि सिस्टम का जीसी इन क्षेत्रों का पता लगाएगा, उनकी सामग्री के बारे में पूर्ण विश्वसनीय जानकारी होगी। विचार नहीं था - यहाँ - कुछ प्रकार के प्लग करने योग्य जीसी का समर्थन करने के लिए, जिसे मैं एक अलग प्रकार की परियोजना मानता हूं। (फिर से, यह चर्चा "क्या हम अपारदर्शी पॉइंटर्स में टैग जोड़ सकते हैं?" के रूप में शुरू हुई।)

बुध, 4 जनवरी, 2017 दोपहर 2:59 बजे, एंड्रयू स्कीडेकर < सूचनाएं @github.com

लिखा था:

टैगिंग चर्चा एक प्रकार से आकर्षक है क्योंकि अब तक,
बाड़ के हमारे पक्ष में चर्चा कुछ ऐसा लेने के बारे में रही है जो हमें अवश्य करना चाहिए
है (एक अपारदर्शी ढेर में संकेत) और एक सस्ती सुविधा जोड़ना

मैं इस बात से असहमत हूं कि एक अपारदर्शी ढेर में पॉइंटर्स की विशेषता है कि WebAssembly
होना आवश्यक है। मैं WebAssembly के लिए तीन संभावित दिशाओं के बारे में सोच सकता हूं
गतिशील और GCed भाषाओं के लिए समर्थन:

1. केवल गैर-जीसीड स्थिर भाषाओं के लिए एक अच्छा वीएम होने की चिंता करें।
2. एक जेएस-इंटर-ऑपरेटेबल टाइप और कचरा एकत्रित ढेर का पर्दाफाश करें।
3. गतिशील रूप से टाइप किए गए को लागू करने के लिए आवश्यक आदिम का पर्दाफाश करें
   WebAssembly में भाषाएँ (या सांख्यिकीय रूप से टाइप की गई GCed भाषाएँ): जैसे JIT
   कोड पैचिंग, लीनियर मेमोरी एकत्रित करने वाले कचरे के लिए स्टैक वॉकिंग, आदि।

एमवीपी ने अपना दायरा 1 दिशा तक सीमित कर दिया है, इसके लिए प्रतिबद्ध नहीं है
यह एमवीपी के बाद।

हां, और यह फीचर रेंगने का विरोध करने और सुनिश्चित करने के लिए बहुत जानबूझकर था
सफलता।

विभिन्न संदर्भों में हमने जो चर्चा की है वह एक _extension_ के रूप में प्रबंधित डेटा है
WebAssembly के लिए (मैं प्रबंधित डेटा एक्सटेंशन, या MDX नाम पर भी विचार करता हूं,
एक अच्छा उम्मीदवार बनने के लिए)। प्रबंधित डेटा एक्सटेंशन WASM कोड की अनुमति देगा
रैखिक मेमोरी से अलग निम्न-स्तरीय संरचना आवंटित करने के लिए
WASM इंजन द्वारा प्रबंधित (यानी GC'd)। स्ट्रक्चर्स को अनुमति देने के लिए टाइप किया जाएगा
अनबॉक्स किए गए फ़ील्ड और निम्न-स्तर पर्याप्त होंगे जो उन्हें लागू करने की अनुमति देंगे
जावा जैसी उच्च स्तरीय भाषाओं का ऑब्जेक्ट मॉडल (vtables, class . के साथ)
पॉइंटर्स, आदि), गो, कार्यात्मक भाषाएँ, आदि।

प्रबंधित डेटा प्रकारों, मानों और ऑपरेटरों को एक एक्सटेंशन के रूप में स्थान देना
एक कोर WASM कार्यान्वयन करना संभव बना देगा जो बस करता है
विस्तार का समर्थन नहीं करते। इस तरह के कार्यान्वयन पर, यह संभव होगा
(हालांकि कुछ काम लेते हैं) एक स्वचालित अनुवाद को लागू करने के लिए जो a . का उपयोग करता है
इनका अनुकरण करने के लिए रैखिक स्मृति (या एक अलग रैखिक स्मृति) का भाग
एक प्रदर्शन नुकसान पर, हालांकि एक जीसी को स्ट्रक्चर और कार्यान्वित करता है।

यह समस्या और GC डिज़ाइन पृष्ठ http://GC.md दूसरा मान
दिशा। उस धारणा के संदर्भ में, GC के लिए टैग बिट्स को उजागर करना
पॉइंटर्स अपारदर्शी जीसी पॉइंटर्स के सस्ते विस्तार के रूप में समझ में आता है
कि "जरूरी" समर्थित होना चाहिए।

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

दूसरी दिशा JVM/.net, या योजना के लिए WASM बैकएंड की भी अनुमति देगी,
या रूबी जावास्क्रिप्ट कचरा संग्रहकर्ता का पुन: उपयोग करने के लिए। हालांकि, कचरा
संग्राहक एक आकार-फिट-सभी नहीं हैं: संभावित परिणाम ऐसा लगता है
WASM VMs के लिए एक टाइप किया हुआ + GCed शामिल करने के लिए एक स्थायी आवश्यकता शुरू करना
ढेर जो कई अनुप्रयोगों की प्रदर्शन आवश्यकताओं को पूरा नहीं करेगा।

तीसरी दिशा में अधिक काम करने की आवश्यकता है, लेकिन लंबी अवधि में दोनों को चाहिए
सरल स्टैंडअलोन WASM VMs की अनुमति दें और ब्राउज़र VMs की जटिलता को कम करें
चूंकि आज के अधिक वीर अनुकूलन प्रयास JavaScript VMs से माइग्रेट होते हैं
WASM सैंडबॉक्स में।

मैंने पहले #733 . बनाया था
https://github.com/WebAssembly/design/issues/733 पर चर्चा करने के लिए
WebAssembly बनाम JavaScript GC हीप को उजागर करने की सापेक्ष प्राथमिकता
कचरा संग्रहकर्ता को लागू करने के लिए आदिम को उजागर करना। शायद आगे
WASM GC की दिशा पर चर्चा वहाँ जारी रह सकती है, और यह मुद्दा
टैग किए गए जीसी पॉइंटर्स पर इस धारणा के साथ ध्यान केंद्रित किया जा सकता है कि समर्थन
जीसी ढेर में अपारदर्शी पॉइंटर्स के लिए डब्ल्यूएएसएम में जोड़ा जाएगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/919#issuecomment-270484689 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALnq1EpdSRskLiuHx4v5M83T4IS9wmx1ks5rPAgggaJpZM4LPxE5
.

@ लार्स-टी-हैनसेन, यह स्पष्ट है कि पूर्णांक के लिए स्पष्ट टैगिंग/अनटैगिंग की आवश्यकता है, लेकिन टाइप सिस्टम में बॉक्सिंग और अनबॉक्स किए गए संदर्भ प्रकारों को अलग करने के लिए उपयोग केस क्या है? क्या अनबॉक्स्ड रेफरेंस पर कोई ऑपरेशन है जो सीधे बॉक्सिंग रेफरेंस पर उपलब्ध नहीं कराया जा सकता है? इस मामले में आपको पूर्व को पेश करने की आवश्यकता नहीं है।

@titzer रे: 'इन

इन "प्रदर्शन नुकसान" की प्रकृति क्या है?

इन संबंधित परियोजनाओं पर मेरे अनुभव से मेरी व्याख्या यह है कि वेब ब्राउज़र विक्रेता समस्या का हिस्सा हैं, या यह कि समझौता करना एक अविश्वसनीय चुनौती है, और इस प्रकार वेब ब्राउज़र विक्रेताओं को उच्च प्रदर्शन निम्न स्तर प्रदान करने के लिए समुदाय को जो चाहिए वह है भाषा ताकि विकास वेब ब्राउज़र विक्रेताओं के बीच समझौते की आवश्यकता से मुक्त हो सके। इसलिए मैं वेब समुदाय के लाभ के लिए उस लक्ष्य पर ध्यान केंद्रित रखने की अपील करता हूं, और यह कि प्रबंधित वस्तुएं उस लक्ष्य से ध्यान भटकाती हैं।

मैं सिर्फ उच्च स्तर की प्रबंधित वस्तुओं को हटा दूंगा और जीसी को वासम से हटा दूंगा, इसे भविष्य की सुविधाओं से हटा दूंगा, कोर पर ध्यान केंद्रित करूंगा और समूहों को उनके ऑब्जेक्ट सिस्टम और जीसी कार्यान्वयन के साथ प्रदर्शन मुद्दों को रिपोर्ट करने के लिए कहूंगा ताकि वे हो सकें मुख्य डिजाइन चुनौती में माना जाता है।

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

मैं सिर्फ उच्च स्तरीय प्रबंधित वस्तुओं को हटा दूंगा और जीसी को wasm से हटा दूंगा, इसे भविष्य की सुविधाओं से हटा दूंगा

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

लीनियर मेमोरी मॉडल में वास्म मेमोरी से जावास्क्रिप्ट ऑब्जेक्ट्स के संदर्भों को लागू करने का कोई तरीका

किसी भी चीज़ के लिए अंतर-भाषा सुविधाओं को संकलित करना आसान है। हमें वास्तव में इसके लिए लक्ष्य समर्थन की आवश्यकता नहीं है। हालाँकि, लक्ष्य के समर्थन के बिना अंतर -भाषा सुविधाओं का संकलन असंभव है। IMO wasm को अंततः हमें JavaScript ऑब्जेक्ट मॉडल (और इस सामान्य मॉडल के माध्यम से, कंपाइल-टू-wasm भाषाओं के बीच) के साथ इंटरऑपरेट करने के लिए सभी उपकरण देने चाहिए। और इसके लिए wasm विनिर्देश में निर्मित एक प्रबंधित मेमोरी मॉडल की आवश्यकता होती है (संभावित रूप से एक विस्तार के रूप में, यदि हम इसे इस तरह से ब्रांड करना चाहते हैं)।

@sjrd इन 'चुनौतियों' को विस्तृत करना अच्छा होगा ताकि उन्हें संबोधित किया जा सके। तो आप जो शो स्टॉपर्स उठा रहे हैं वे हैं:

• एक जेएस ऑब्जेक्ट के लिए wasm सैंडबॉक्स में एक पूर्णांक मैप करना, लेकिन यह हैश टेबल या सरणी का उपयोग करके काफी संभव लगता है, यह बस इतना ही कुशल है, और यह कितना कुशल होना चाहिए? यह पहले से ही गेम आदि में किया जा चुका है। पॉइंटर्स की सुरक्षा को पूरा करने वाला एक अधिक कुशल हैश संभव हो सकता है, इसलिए यदि आवश्यक हो तो इसे एक्सप्लोर करें।

• आप सर्कुलर संदर्भों के मुद्दे को भी उठाते हैं, इसलिए मुझे लगता है कि आपकी चिंता यह है कि जेएस जीसी कैसे इन जीसी पॉइंटर्स को वासम वीएम में पूर्णांक के रूप में संग्रहीत कर सकता है? लेकिन जेएस से पॉइंटर्स के बारे में रैखिक स्मृति में भी वस्तुओं के बारे में क्या?

इन मुद्दों को सामान्य रूप से प्रबंधित वस्तुओं और प्रबंधित GC को wasm में जोड़कर संबोधित नहीं किया जा सकता है, जब तक कि यह स्वीकार नहीं किया जाता है कि सामान्य wasm कोड में प्रबंधित वस्तुओं और प्रबंधित GC का उपयोग किया जाता है और यह मूल रूप से कोर wasm प्रोजेक्ट को इसे मॉर्फ करने के लिए छोड़ देगा। उच्च स्तरीय वीएम डिजाइन।

इसलिए हम कुछ समाधानों का पता लगा सकते हैं: एक जेएस जीसी हुक जो वासम सैंडबॉक्स में कॉल करता है ताकि पॉइंटर्स को परिमार्जन किया जा सके जो जेएस ऑब्जेक्ट्स को वापस संदर्भित कर सकते हैं और जिनके पास जेएस जीसी को वापस संवाद करने का कुछ परिभाषित तरीका होगा। यह केवल कुछ परिभाषित FFI कॉल हो सकते हैं जो wasm कोर डिज़ाइन और सैंडबॉक्स पर कोई बोझ नहीं डालते हैं। यह उस प्रकार की सोच है जो सभी समस्याओं को हल करने के लिए वासम पर निर्भर रहने के प्रलोभन के बिना उत्पन्न होने की आवश्यकता है।

@sjrd आप 'वितरित कचरा संग्रह' भी देख सकते हैं जो एक ढांचा हो सकता है जो आपके उपयोग के मामले को वासम के बोझ के बिना संबोधित कर सकता है। मुझे यकीन नहीं है कि जेएस के पास सभी आवश्यक समर्थन हैं, लेकिन यदि आवश्यक हो तो जेएस को क्लाउड ऑब्जेक्ट स्टोर्स आदि के लिए उस समर्थन को जोड़ने में अधिक सामान्य रुचि हो सकती है, और यह वासम सीजी के बाहर किया जा सकता है। wasm पक्ष केवल पूर्णांक wasm कोड होगा, इसलिए एक अलग प्रोजेक्ट हो सकता है (या कई प्रोजेक्ट यदि वेब ब्राउज़र विक्रेता और/या वेब समुदाय सहमत नहीं हो सकते हैं)। शायद कई ऐप्स के लिए सरल रणनीतियां जैसे संदर्भ गिनती, कमजोर पॉइंटर्स, और लीज पॉइंटर्स वासम और जेएस उदाहरणों में वैश्विक कचरा संग्रह की जटिलता के बिना पर्याप्त होंगे। एक अन्य विकल्प यह देखने के लिए हो सकता है कि क्या इन ढांचे में अधिक जेएस कोड को सैंडबॉक्स में ले जाया जा सकता है - क्या कोई वासम के लिए जेएस दुभाषिया लिख ​​सकता है जिसमें विविध जेएस कोड के लिए पर्याप्त प्रदर्शन है जो एक बड़े कोड बेस का एक छोटा सा हिस्सा है।

@ रॉसबर्ग-क्रोमियम,

यह स्पष्ट है कि पूर्णांकों के लिए स्पष्ट टैगिंग/अनटैगिंग की आवश्यकता है, लेकिन टाइप सिस्टम में बॉक्सिंग और अनबॉक्स किए गए संदर्भ प्रकारों को अलग करने के लिए उपयोग केस क्या है? क्या अनबॉक्स्ड रेफरेंस पर कोई ऑपरेशन है जो सीधे बॉक्सिंग रेफरेंस पर उपलब्ध नहीं कराया जा सकता है? इस मामले में आपको पूर्व को पेश करने की आवश्यकता नहीं है।

आप नहीं जानते कि बॉक्स में कोई संदर्भ है या नहीं। ऐसा होने पर, एक बॉक्स पर सीधे एक पॉइंटर ऑपरेशन (जो प्रति समस्याग्रस्त नहीं है) को पॉइंटर बिट की जांच करनी होगी और किसी भी टैग को स्ट्रिप करना होगा। Ptr पर एक पॉइंटर ऑपरेशन को कभी भी ऐसा करने की आवश्यकता नहीं होगी। तो मेरे दृष्टिकोण से यह सिर्फ एक दक्षता चिंता थी।

@ लार्स-टी-हैनसेन, आह, तो आईआईयूसी कच्चे पॉइंटर्स टाइप किए जाएंगे लेकिन बॉक्स किए गए हैं? AFAICS, यह वह कारक नहीं है जो आप चाहते हैं, क्योंकि तब बॉक्सिंग पॉइंटर के माध्यम से प्रत्येक एक्सेस के लिए पहले रनटाइम चेक की आवश्यकता होगी - और एक बॉक्सिंग पॉइंटर केवल एक चीज है जिसे आप जीसीड मेमोरी में स्टोर कर सकते हैं। तो स्मृति ग्राफ चलने के लिए प्रत्येक किनारे पर रनटाइम जांच की आवश्यकता होगी।

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

@ रॉसबर्ग-क्रोमियम, वास्तव में मैंने इस बात पर प्रकाश डाला है कि मुझे कैसे लगता है कि हम यहां प्रकार की जानकारी को ट्रैक करेंगे। मैंने किसी बिंदु पर कल्पना की थी कि Boxes प्रकार की जानकारी को ट्रैक कर सकते हैं, अर्थात Box(Ptr .)) जहां T एक स्ट्रक्चर प्रकार है, एक डेटाम प्राप्त करेगा जो या तो एक टैग किए गए पॉइंटर-टू-टी या एक (टैग किए गए) पूर्णांक को धारण करने के लिए जाना जाता है। उस स्थिति में, बॉक्स को सीधे संदर्भित करने के लिए अभी भी पॉइंटर-नेस (यह एक int हो सकता है) की जांच करने की आवश्यकता होगी, और फिर भी टैग को हटाने की आवश्यकता होगी (क्योंकि टैग में अज्ञात बिट्स सेट हैं)।

आपका रेफरी (टी) विचार स्पष्ट रूप से संबंधित है लेकिन पॉइंटर को टैग करने की इजाजत नहीं देता है, अगर मैं सही ढंग से समझता हूं, कम से कम उपयोगकर्ता द्वारा परिभाषित टैग के साथ नहीं, जो समस्या मैं अपने डिजाइन के साथ हल करने की कोशिश कर रहा था।

(+1 टाइप सिस्टम के माध्यम से किसी भी तरह से नलप्टर को बाधित करने पर, मुझे लगता है कि यह टैग के लिए ऑर्थोगोनल है।)

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

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

@wllang

अच्छा होगा कि इन 'चुनौतियों' का विस्तृत विवरण दिया जाए ताकि इनका समाधान किया जा सके।

मैं सहमत हूं। मैं कुछ समय से ऐसा करने की योजना बना रहा हूं, लेकिन अभी तक इसे करने के लिए तैयार नहीं हुआ हूं।

एक जेएस ऑब्जेक्ट के लिए wasm सैंडबॉक्स में एक पूर्णांक मैप करना, लेकिन यह हैश टेबल या सरणी का उपयोग करके काफी संभव लगता है, यह बस इतना ही कुशल है, और यह कितना कुशल होना चाहिए?

IMO इसे कम से कम उतना ही कुशल होना चाहिए जितना कि जावास्क्रिप्ट में हीप ऑब्जेक्ट्स

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

इन मुद्दों को सामान्य रूप से प्रबंधित वस्तुओं और प्रबंधित GC को wasm में जोड़कर संबोधित नहीं किया जा सकता है, जब तक कि यह स्वीकार नहीं किया जाता है कि सामान्य wasm कोड में प्रबंधित वस्तुओं और प्रबंधित GC का उपयोग किया जाता है और यह मूल रूप से कोर wasm प्रोजेक्ट को इसे मॉर्फ करने के लिए छोड़ देगा। उच्च स्तरीय वीएम डिजाइन।

इसे संबोधित किया जा सकता है, उदाहरण के लिए, यदि wasm में दो मेमोरी स्पेस हैं: रैखिक मेमोरी जो अब है, मुख्य रूप से wasm को संकलित करने वाली अप्रबंधित भाषाओं द्वारा उपयोग की जाती है; और जावास्क्रिप्ट हीप के साथ संयुक्त GC का समर्थन करने वाला GC'ed हीप, मुख्य रूप से wasm को संकलित करने वाली प्रबंधित भाषाओं द्वारा उपयोग किया जाता है। ध्यान दें कि एक प्रबंधित भाषा शायद "ऑफ-हीप" आवंटन के लिए रैखिक स्मृति का उपयोग करेगी (उदाहरण के लिए, जावा में ByteBuffer.allocatedDirect() ); और अप्रबंधित भाषाएं शायद जावास्क्रिप्ट के साथ इंटरऑपरेबिलिटी परिदृश्यों के लिए प्रबंधित मेमोरी का उपयोग करेंगी।

यह केवल कुछ परिभाषित FFI कॉल हो सकते हैं जो wasm कोर डिज़ाइन और सैंडबॉक्स पर कोई बोझ नहीं डालते हैं।

मैं जीसी विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि "जीसी में बस कुछ सार्वजनिक रूप से निर्दिष्ट हुक" वासम कोर डिजाइन और/या वीएम कार्यान्वयन पर एक महत्वपूर्ण बोझ हो सकते हैं।

एक अन्य विकल्प यह देखने के लिए हो सकता है कि क्या इन ढांचे में अधिक जेएस कोड को सैंडबॉक्स में ले जाया जा सकता है - क्या कोई वासम के लिए जेएस दुभाषिया लिख ​​सकता है जिसमें विविध जेएस कोड के लिए पर्याप्त प्रदर्शन है जो एक बड़े कोड बेस का एक छोटा सा हिस्सा है।

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

@sjrd

IMO इसे कम से कम उतना ही कुशल होना चाहिए जितना कि जावास्क्रिप्ट में हीप ऑब्जेक्ट्स में हेरफेर करने वाला समान कोड लिखना। मुझे नहीं लगता कि हम एक पूर्णांक मानचित्र के साथ इस स्तर के प्रदर्शन के करीब कहीं भी पहुंच सकते हैं।

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

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

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

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

इसे संबोधित किया जा सकता है, उदाहरण के लिए, यदि wasm में दो मेमोरी स्पेस हैं: रैखिक मेमोरी जो अब है, मुख्य रूप से wasm को संकलित करने वाली अप्रबंधित भाषाओं द्वारा उपयोग की जाती है; और जावास्क्रिप्ट हीप के साथ संयुक्त GC का समर्थन करने वाला GC'ed हीप, मुख्य रूप से wasm को संकलित करने वाली प्रबंधित भाषाओं द्वारा उपयोग किया जाता है।

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

मैं जीसी विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि "जीसी में बस कुछ सार्वजनिक रूप से निर्दिष्ट हुक" वासम कोर डिजाइन और/या वीएम कार्यान्वयन पर एक महत्वपूर्ण बोझ हो सकते हैं।

कुछ आयातित/निर्यात किए गए फ़ंक्शन नामों को परिभाषित करना wasm डिज़ाइन पर बोझ नहीं है, लेकिन JS GC कार्यान्वयन पर बोझ काफी हो सकता है और अगर ग्लोबल GC एक शो स्टॉपर है, तो यह विचार करने योग्य है।

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

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

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

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

मैं जेएस वीएम को व्यक्त करने के लिए पर्याप्त लचीला होने के कारण वासम एन्कोडिंग का भी समर्थन करता हूं, जो इतना बड़ा बोझ नहीं लगता है और वैसे भी भविष्य के सबूत में मदद करेगा। मुझे आश्चर्य है कि क्या मैं वेब पर उच्च प्रदर्शन निम्न स्तर का वीएम देखने के लिए जीवित रहूंगा।

@ रॉसबर्ग-क्रोमियम

दूसरी ओर, V8 में प्रत्येक मान के लिए स्थान बर्बाद किए बिना हीप मान के मानचित्र ("छिपे हुए वर्ग") में बड़े टैग को कुशलतापूर्वक संग्रहीत करने के कई तरीके होंगे।

Fwiw यह एक "वर्ग" ऑब्जेक्ट में पॉइंटर टैग संग्रहीत करने का सुझाव देने में थोड़ा अजीब लगता है क्योंकि यहां चर्चा किए जा रहे पॉइंटर टैग प्रति-पॉइंटर प्रति-वर्ग नहीं हैं, शायद v8 पॉइंटर्स को एक से अधिक शब्दों में स्टोर करता है लेकिन यह आश्चर्यजनक होगा और दिलचस्प डिजाइन? इन टैग्स को उस ऑब्जेक्ट में स्टोर करना भी संभव नहीं होगा जिसे पॉइंटर इंगित कर रहा था क्योंकि ऑब्जेक्ट टैग बिट्स में एन्कोडेड तत्काल मान हो सकता है।

@sjrd बस यह स्थापित करने के लिए कि जीसी मुद्दे में इस मंच (पेटेंट) में उठाए गए समाधान हैं, यहां एक समाधान है। JS GC एक नई तालिका जोड़ता है जो JS पॉइंटर्स और पूर्णांकों (wasm साइड पॉइंटर्स) के बीच मैप करता है। यह सीधे लीनियर मेमोरी में टेबल के वासम साइड को बनाए रख सकता है, इसलिए JS टेबल एक एरे बफर और एक रेंज को संदर्भित करता है। प्रत्येक तरफ एक live ध्वज और प्रति सूचक एक संदर्भ गणना है। जब एक पॉइंटर को टेबल में जोड़ा जाता है तो लाइव फ्लैग सेट हो जाता है और रेफरेंस काउंट टेबल के उस तरफ एक पर सेट हो जाता है। जब दोनों तरफ जीसी चलता है तो यह आखिरी तक इन तालिकाओं को साफ करने से रोकता है, इसलिए उस बिंदु पर यह जानता है कि संबंधित पक्ष के इन पॉइंटर्स में टेबल के बाहर से उस तरफ से लाइव पॉइंटर्स हैं, और यह संबंधित पक्ष के लिए लाइव फ्लैग अपडेट करता है। यदि लाइव फ्लैग स्पष्ट है और दूसरी तरफ संदर्भ संख्या शून्य है तो पॉइंटर को पुनः प्राप्त किया जाता है और तालिका से हटा दिया जाता है। इन सभी तालिकाओं को संभालने के बाद, जीसी लाइव पॉइंटर्स को उनके द्वारा संदर्भित किसी भी चीज़ को लाइव रखते हुए परिमार्जन करना जारी रखता है। जेएस पक्ष पर, ये पॉइंटर्स या तो केवल लिखने के लिए होते हैं या जेएस पक्ष पर नहीं रहने के रूप में ध्वजांकित होने के बाद अपठनीय हो जाते हैं - वासम पक्ष जीसी से समान अर्थशास्त्र का पालन करने की उम्मीद की जाएगी (तालिका धारण करने वाली रैखिक स्मृति अभी भी पठनीय है लेकिन कोड लागू होता है ऑब्जेक्ट सिस्टम अपरिवर्तनीय है कि वे पठनीय नहीं हैं)। किसी भी तरफ जीसी के बाद, एक एसिंक कॉल ट्रिगर किया जाता है यदि पॉइंटर्स को लाइव नहीं के रूप में चिह्नित किया जाता है, तो यह संदर्भ संख्या को अपडेट करने के लिए दूसरी तरफ कॉल कर सकता है और जब यह शून्य हो जाता है तो पॉइंटर अगले जीसी पर पुनः प्राप्त किया जाएगा। इन तालिकाओं का उपयोग वैश्विक जीसी के लिए एक ही धागे के बाहर ऑब्जेक्ट स्टोर के लिए किया जा सकता है और जेएस समुदाय के बीच इस तरह की सुविधा में अधिक सामान्य रुचि हो सकती है।

@wllang , व्यक्तिगत मूल्यों के प्रतिनिधित्व को ट्रैक करने के लिए मानचित्र/छिपे हुए वर्ग एक सामान्य कार्यान्वयन तकनीक हैं; वे कक्षा की भाषा-स्तर की धारणाओं से केवल शिथिल रूप से संबंधित हैं।

@ रॉसबर्ग-क्रोमियम v8 में छिपी हुई कक्षाओं के बारे में जो मैं समझता हूं, वे वस्तु में एक स्लॉट के रूप में संग्रहीत हैं। यह पीआर टैग किए गए पॉइंटर्स के बारे में है, इसलिए टैग को एक अलग ऑब्जेक्ट स्लॉट में संग्रहीत करना भी प्रासंगिक नहीं लगता है, उन्हें छिपे हुए वर्ग में संग्रहीत करने वाला थोड़ा अकेला है, बल्कि उन्हें पॉइंटर में संग्रहीत करने की आवश्यकता है, इस प्रकार कार्यान्वयन केवल यह तय करने के लिए स्वतंत्र हो सकता है कि कौन से बिट्स पॉइंटर्स का उपयोग करने के लिए। या आपके मन में कुछ और था जो मैं अभी समझ नहीं पाया। शायद ये स्लाइड दूसरों की मदद करें http://thlorenz.com/talks/demystifying-v8/talk.pdf

@wllang , मैंने जो कहा वह यह है कि _where_ टैग को वास्तव में संग्रहीत करने का कोई मतलब नहीं है, क्योंकि आर्किटेक्चर और वीएम में गंभीर और बेतहाशा अलग-अलग बाधाएं हैं। कई कार्यान्वयन रणनीतियों की अनुमति देने के लिए Wasm के लिए टैगिंग समर्थन पर्याप्त रूप से सारगर्भित होना चाहिए।

संभावित विस्तार के रूप में GC प्रस्ताव (https://github.com/WebAssembly/gc/) में शामिल है।

अरे @ lars-t-hansen और @qwertie - मैं यहां सबसे अलग रहूंगा। निरंतरता एक ऐसी विशेषता है जिसे कोई सम्मान नहीं मिलता है; और फिर, लोगों को अंत में उन्हें कठिन तरीके से पुन: आविष्कार करना पड़ता है। एक बार जब आप उन्हें प्राप्त कर लेते हैं, तो आपके पास स्वचालित रूप से coroutines, microthreads, जनरेटर, goroutines, आपके पास क्या है, मुफ्त में है। _And_ आपके पास एक आदिम है जिसके साथ आप और भी चीजें बना सकते हैं जिनकी आपने पहले कल्पना नहीं की थी; उदाहरण के लिए:

• पाइरेट का reactor फीचर और DrRacket का big-bang फीचर आपको प्रोग्रामिंग भाषा में प्रथम श्रेणी का इवेंट-लूप एब्स्ट्रैक्शन देता है। ब्राउज़र में इसे लागू करने के लिए आपको किसी प्रकार की निरंतरता जैसी सहायता की आवश्यकता है।

• DrRacket की send/suspend सुविधा (चूंकि स्मॉलटाक सीसाइड फ्रेमवर्क और दूसरों के एक समूह द्वारा नकल की गई है) - सर्वर-साइड वेब प्रोग्रामिंग के लिए प्रत्यक्ष शैली में - लगभग पूरी तरह से निरंतरता की आवश्यकता होती है और यदि आपके पास है तो इसे लागू करने के लिए तुच्छ है।

ध्यान दें कि इनमें से कोई भी call/cc ही नहीं है - यह एक असंबंधित, निफ्टी प्रोग्रामर एब्स्ट्रैक्शन है जो कि निरंतरता के साथ बनाना आसान होता है और बिना निर्माण करना असंभव होता है।

WeScheme [http://www.wescheme.org/] और Pyret [https://www.pyret.org/] दोनों के कार्यान्वयनकर्ताओं ने इसकी कमी के लिए बड़े पैमाने पर कीमत चुकाई है। दोनों दर्द से, धीरे-धीरे, कार्यक्रम परिवर्तन द्वारा इसे प्राप्त करने के लिए नारे लगाते हैं, इस प्रकार की सुविधाओं को सक्षम करने के लिए, बड़े पैमाने पर प्रदर्शन दंड _and_ जटिलता ओवरहेड के साथ।

यदि आप अपनी खुद की _उपयोगकर्ता-सामना करने वाली प्रोग्रामिंग भाषा_ बना रहे हैं, तो यह कहना पूरी तरह से उचित है कि "मैं डिक्री करता हूं कि नियंत्रण का कोई गैर-स्थानीय हस्तांतरण नहीं होगा"। यदि आप एक _assembly_ का निर्माण कर रहे हैं, तो मुझे लगता है कि आपको "निरंतरता से परे सोचना होगा और केवल योजना के पास वैसे भी हैं और जो उस मामले के लिए योजना का उपयोग करते हैं" और बड़ी संख्या में निष्पादन नियंत्रण आदिमों पर विचार करें जो आधुनिक भाषाओं में हैं और लोग आविष्कार करते रहते हैं .

चूंकि ब्राउज़र के लोगों ने न तो निरंतरता और न ही कोरआउट्स/स्टैक-स्विचिंग का समर्थन करने का निर्णय लिया है, यह एक महत्वपूर्ण मुद्दा है, लेकिन मैं उत्सुक हूं - क्या आप वर्णन कर सकते हैं कि ये विशेषताएं क्या करती हैं, ताकि मैं देख सकूं कि कोरआउटिन का उपयोग करके उन सुविधाओं का निर्माण क्यों संभव नहीं है /स्टैक-स्विचिंग एक आदिम के रूप में?

अधिकांश भाग के लिए Coroutines पर्याप्त है। वे निश्चित रूप से चाल चलेंगे
यहां।

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