WebAssembly पर GC भाषाएँ लाने का एक नया, अधिक कुशल तरीका

 (v8.dev)
4 पॉइंट द्वारा GN⁺ 2023-11-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Java, Kotlin, Dart, Python, C# जैसी GC भाषाओं को WebAssembly पर लाने में WasmGC, मौजूदा VM को फिर से compile करने के बजाय Wasm के अपने GC structs, arrays और type system का उपयोग करता है
  • पारंपरिक WasmMVP porting में मौजूदा VM और optimizations का पुनः उपयोग करना आसान है, लेकिन linear memory के भीतर GC या malloc/free साथ लाने की लागत, stack references, circular references और fragmentation जैसी सीमाएँ होती हैं
  • WasmGC में VM objects और memory को सीधे manage करता है, जिससे binary size घट सकती है; fannkuch benchmark में यह 2.3K था, जो C/Rust के 6.1~9.6K से छोटा था
  • WasmGC एक उच्च-स्तरीय intermediate representation है, इसलिए Binaryen wasm-opt और V8 runtime optimizations महत्वपूर्ण हैं; Java benchmarks में औसतन 1.9× और Google Sheets Calc Engine में लगभग 30% सुधार देखा गया
  • Standardization और browser support आगे बढ़ चुके हैं, लेकिन यह मौजूदा VM को ज्यों का त्यों compile करने का तरीका नहीं है, इसलिए language constructs को WasmGC primitives तक lower करने के लिए नए toolchain कार्य की आवश्यकता है

GC भाषाओं को Wasm पर लाने के दो तरीके

  • GC भाषाओं को WebAssembly पर port करने के दो बड़े रास्ते हैं
    • पारंपरिक porting: मौजूदा language VM को 2017 में जारी WebAssembly Minimum Viable Product, यानी WasmMVP, पर compile करना
    • WasmGC porting: GC proposal में परिभाषित Wasm की GC संरचनाओं पर language को compile करना
  • पारंपरिक porting उस मॉडल के करीब है जिसमें किसी भाषा को नए CPU architecture पर ले जाते समय VM का parser, library support, GC और optimizer साझा किया जाता है, और केवल नया backend जोड़ा जाता है
  • WasmGC porting किसी भाषा को नए architecture पर नहीं, बल्कि नए VM पर ले जाने के अधिक करीब है
    • Java को JavaScript में compile करने वाले J2CL की तरह, language objects को target VM के objects के रूप में व्यक्त किया जाता है और target VM का GC उन्हें manage करता है
    • WasmGC, JavaScript VM, JVM और CLR की तुलना में lower-level होने का लक्ष्य रखता है, लेकिन VM-managed structs, arrays और type relationships देने के कारण यह WasmMVP से higher-level है

पारंपरिक WasmMVP porting के फायदे और सीमाएँ

  • मौजूदा VM code, language implementation और optimizations को लगभग ज्यों का त्यों reuse कर पाना पारंपरिक porting का सबसे बड़ा लाभ है
    • Python का Pyodide और C# का Blazor इसके प्रमुख उदाहरण हैं
    • Blazor, AOT और JIT दोनों compilation को support करता है
  • WasmMVP output, WasmMVP की मूल संरचनाओं जैसे linear memory, tables और functions का उपयोग करता है
  • कई बार Wasm को ऐसे VM के भीतर चलाया जाता है जिनमें पहले से GC मौजूद है, जैसे browser, Node.js, workerd, Deno, Bun
    • ऐसे माहौल में GC implementation को Wasm binary में शामिल करने से अनावश्यक size increase होता है
    • C, C++, Rust जैसी linear memory इस्तेमाल करने वाली भाषाओं में भी यदि meaningful allocation करना हो तो malloc/free code साथ शामिल करना पड़ता है
    • dlmalloc 6K का है, और size-priority वाला emmalloc भी 1K से बड़ा है
  • WasmGC में VM memory को automatically manage करता है, इसलिए Wasm के भीतर GC या malloc/free जोड़ने की जरूरत नहीं होती
    • WasmGC पर पहले लिखे गए लेख के fannkuch benchmark में WasmGC 2.3K था, जबकि C/Rust 6.1~9.6K थे

Circular collection, stack references, fragmentation

  • Browser में Wasm अक्सर JavaScript और Web API के साथ interact करता है, लेकिन केवल WasmMVP और reference types के सहारे Wasm और JS के बीच दो-तरफ़ा links में fine-grained circular collection कठिन है
    • JS object links केवल Wasm tables में रखे जा सकते हैं
    • JS से Wasm की ओर लौटने वाले links पूरे Wasm instance को एक बड़े object की तरह reference कर सकते हैं
    • WasmGC VM द्वारा पहचाने जाने वाले Wasm objects को define करता है, इसलिए Wasm और JavaScript के बीच सही references बनाए जा सकते हैं
  • GC भाषाओं को call scope के local variables जैसे stack पर मौजूद references भी पहचानने होते हैं
    • पारंपरिक porting में Wasm sandboxing के कारण program अपनी stack inspect नहीं कर सकता
    • विकल्प के तौर पर shadow stack का उपयोग किया जा सकता है, या GC केवल तब चलाया जा सकता है जब stack पर references न हों, जैसे JavaScript event loop के turns के बीच
    • भविष्य में Wasm का stack scanning support पारंपरिक porting में मदद कर सकता है
    • अभी stack references को बिना overhead के automatically handle करने का तरीका WasmGC है
  • WasmMVP की linear memory में malloc/free, लंबे समय तक चलने वाले programs में memory fragmentation पैदा कर सकता है
    • कुल unused memory पर्याप्त होने पर भी यदि बड़ा contiguous block न हो तो बड़ा allocation fail हो सकता है
    • Fragmentation, Wasm module को memory अधिक बार बढ़ाने पर मजबूर कर सकता है, जिससे overhead और out-of-memory errors हो सकते हैं
    • WasmGC में VM GC heap को compact करने के लिए objects को move कर सकता है, इसलिए fragmentation से बचा जा सकता है

Developer tools और language semantics

  • पारंपरिक WasmMVP porting में objects, linear memory के bytes के रूप में रखे जाते हैं, इसलिए developer tools के लिए higher-level type information देखना कठिन होता है
  • WasmGC में VM GC objects को manage करता है, इसलिए tools integration आसान हो जाता है
    • Chrome DevTools के Memory tab में WasmGC program का heap snapshot देखा जा सकता है
    • Linked list example में $Node type name और अगले object को reference करने वाला $next field दिखाई देता है
    • Object count, shallow size, retained size जैसी सामान्य heap snapshot information भी मिलती है
    • Chrome DevTools का debugger भी WasmGC objects पर काम करता है
  • पारंपरिक porting मौजूदा VM को recompile करता है, इसलिए अपेक्षित language semantics को बनाए रखना आसान होता है
  • WasmGC porting में language constructs को नए GC types यानी structs और arrays के रूप में व्यक्त करना पड़ता है, इसलिए efficiency के लिए semantics में समझौते की जरूरत पड़ सकती है
    • WasmGC struct fields के fixed index और types होते हैं, इसलिए जो भाषाएँ fields को अधिक dynamic तरीके से access करना चाहती हैं उन्हें कठिनाई हो सकती है
    • WasmGC में अभी interior pointer नहीं है, और उम्मीद है कि समय के साथ ऐसी सीमाएँ सुधरेंगी
  • Target VM पर compile करने के अन्य उदाहरणों में भी semantics choices मौजूद होती हैं

WasmGC porting के लिए आवश्यक toolchain कार्य

  • WasmGC porting, मौजूदा VM को simply recompile करने का तरीका नहीं है
    • कुछ code, जैसे parser logic या AOT optimizations, जो runtime GC के साथ सीधे integrate नहीं होते, reuse किए जा सकते हैं
    • लेकिन सामान्यतः language constructs को WasmGC structs और arrays तक lower करने के लिए काफी नया code चाहिए
  • Lua VM जैसे C में लिखे VM को कुछ ही मिनटों में Wasm पर compile किया जा सकता है, लेकिन Lua के WasmGC port में यह तय और लागू करना होगा कि Lua constructs को WasmGC type system की सीमाओं के भीतर कैसे व्यक्त किया जाए
  • WasmGC porting की बड़ी कमी toolchain effort है
  • आदर्श स्थिति यह है कि WasmGC type system सभी भाषाओं को efficiently support करे, और हर भाषा अपना WasmGC port implement करे
    • WasmGC type system में भविष्य की additions पहले हिस्से में मदद कर सकती हैं
    • साझा common toolchain work, दूसरे हिस्से का बोझ कम कर सकता है

WasmGC बेहतर optimize क्यों हो सकता है

  • WasmGC, WasmMVP की तुलना में एक higher-level intermediate representation है, इसलिए optimization की गुंजाइश अधिक है
  • उदाहरण के तौर पर, जो code दो बार GC object allocate करता है, field में 10 store करता है और फिर return करता है, उसे तार्किक रूप से return 10 तक घटाया जा सकता है
    • WasmMVP में allocation, malloc calls में बदल जाता है, और malloc linear memory पर side effects वाला complex function है, इसलिए optimizer के लिए यह तय करना कठिन होता है कि दूसरा allocation पहले object के field को नहीं बदलेगा
    • WasmGC में allocation, struct.new instruction के रूप में व्यक्त होता है, जिस पर VM operations के रूप में reasoning की जा सकती है, इसलिए references और field values को track किया जा सकता है
  • WasmGC explicit function pointer ref.func, उसके जरिए call call_ref, और struct/array field types भी प्रदान करता है
  • WasmMVP native-जैसी speed इसलिए दे पाता है क्योंकि आम तौर पर LLVM जैसे शक्तिशाली optimizing compilers, Wasm generate होने से पहले ही अधिकांश optimizations कर देते हैं
  • LLVM, WasmGC को support नहीं करता, और कई GC भाषाएँ LLVM का उपयोग भी नहीं करतीं, इसलिए WasmGC को अलग optimization model की जरूरत है

Binaryen और wasm-opt optimizations

  • WasmGC में general-purpose optimizations को Wasm तक lower करने के बाद किया जा सकता है, जिससे कई language toolchains एक साझा Wasm-to-Wasm optimizer का उपयोग कर सकते हैं
  • V8 टीम ने WebAssembly toolchain optimization project Binaryen में WasmGC support पर निवेश किया है
    • हर toolchain, command-line tool wasm-opt के जरिए Binaryen का उपयोग कर सकता है
  • Binaryen के पास पहले से WasmMVP के लिए inlining, constant propagation, dead code elimination जैसी optimizations हैं, और इनमें से अधिकांश WasmGC पर भी लागू होती हैं
  • WasmGC के लिए जोड़ी गई प्रमुख optimizations ये हैं
  • Binaryen की नई GC optimizations और उनके उपयोग को Binaryen docs में संकलित किया गया है
  • J2Wasm output पर Java performance नापने पर wasm-opt ने हर benchmark में speed बढ़ाई, और औसतन 1.9× तेजी मिली

V8 में WasmGC optimizations

  • GC भाषाओं का performance model, C, C++, Rust जैसी भाषाओं से अलग है जो compile-time inlining पर बहुत निर्भर करती हैं
    • Java, Dart जैसी GC भाषाओं में आम तौर पर VM runtime पर inlining और optimizations करता है
  • Java में हर call शुरुआत में indirect call के रूप में शुरू होता है
    • Child classes parent functions को override कर सकती हैं, और parent type reference से child को call करने पर भी यही लागू होता है
    • Toolchain यदि indirect calls को direct calls में बदल दे तो लाभ होता है, लेकिन वास्तविक Java code में कई रास्ते ऐसे होते हैं जहाँ इसे statically infer करना कठिन है
  • V8 ने WasmGC के लिए speculative inlining लागू किया है
    • यह runtime पर indirect calls को observe करता है
    • यदि कोई particular callsite कम call targets वाला सरल व्यवहार दिखाए, तो guard checks के साथ उसे inline कर दिया जाता है
  • Google Sheets Calc Engine, spreadsheet formulas की गणना करने वाला Java codebase है, जिसे पहले J2CL के जरिए JavaScript में compile किया जाता था
    • V8 टीम ने Sheets और J2CL के साथ मिलकर इस code को WasmGC पर port किया
    • इस code में speculative inlining, WasmGC के लिए V8 द्वारा लागू किए गए किसी भी एक optimization में सबसे प्रभावी साबित हुआ
    • लगभग 30% speedup मिला, जो अन्य मापी जा सकने वाली सभी optimizations के संयुक्त प्रभाव से भी बड़ा था
  • V8 की अन्य WasmGC optimizations में load elimination, type-based optimizations, branch elimination, constant folding, escape analysis, common subexpression elimination आदि शामिल हैं
  • WasmGC की type information runtime optimizations में भी उपयोग होती है
    • यदि ref.test किसी specific type check को pass करता है, तो उसी type पर ref.cast सफल होना चाहिए
    • Java में instanceof के बाद downcast जैसे patterns में cast हटाया जा सकता है
  • WasmMVP में toolchain और VM optimizations की भूमिका अपेक्षाकृत स्पष्ट रूप से बंटी हुई थी, लेकिन WasmGC में GC भाषाओं की प्रकृति और WasmGC representation की optimization क्षमता के कारण toolchain और VM optimizations अधिक overlap कर सकते हैं

वर्तमान स्थिति और शुरुआत कहाँ से करें

  • WasmGC, W3C में phase 4 तक पहुँच चुका है और अब एक पूर्ण, final standard है
  • Chrome 119 में WasmGC support शामिल है
  • उम्मीद है कि Firefox 120 उसी महीने के अंत में WasmGC support के साथ जारी होगा
  • Flutter demo में WasmGC पर compile किया गया Dart, widgets, layout और animations सहित application logic चलाता है
  • WasmGC support करने वाले toolchains ये हैं
  • Developer tools सेक्शन का छोटा उदाहरण source code, हाथ से लिखा गया “hello world” WasmGC program है
    • इसमें $Node type definition और struct.new के जरिए construction देखा जा सकता है
  • Binaryen wiki बताता है कि compiler ऐसा WasmGC code कैसे emit करे जिसे optimizers अच्छी तरह optimize कर सकें
    • GC Implementation - Lowering Tips
    • Java, Dart और Kotlin toolchains द्वारा उपयोग किए जाने वाले Binaryen passes और flags भी देखे जा सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-04
Hacker News की रायें

  • WASM thin waist का उदाहरण लगता है, और अगर इसमें garbage collector भी जुड़ जाए तो यह N×M नहीं बल्कि N+M संरचना बन जाता है। यानी यह N भाषाओं + M virtual machines + G garbage collectors की दिशा में जा सकता है, और V8 में पहले से ही एक mature garbage collector है
    मैं सोच रहा था कि WASM से JVM तक जाने वाला कोई tool है या नहीं, और GitHub पर एक मिला। मैंने इसे खुद इस्तेमाल नहीं किया है; बस इसलिए देखा क्योंकि JVM भी mature और parallel garbage collector रखता है
    मुझे उम्मीद नहीं थी कि WASMGC इतनी जल्दी आ जाएगा, इसलिए अब I/O parallelism ही नहीं बल्कि वास्तविक parallelism के लिए WASM Threads की भी उम्मीद है
    अगर async, parallelism और garbage collection को प्रभावी ढंग से हल करने का मौका मिलता है, तो WASM और मजबूत हो सकता है और developers के लिए भ्रम या कठिनाई का स्रोत नहीं बनेगा। मेरे हिसाब से WASI के महत्वपूर्ण होने की वजह भी यही है कि यह POSIX जितना स्थिर API परिभाषित करने का मौका देता है
    1: https://www.oilshell.org/blog/2022/02/diagrams.html
    2: https://github.com/cretz/asmble

    • https://github.com/cretz/asmble ठीक से काम करता है, लेकिन यह ज्यादातर मजे के लिए बनाया गया project था और अब वास्तव में maintain नहीं किया जाता
      WASM intermediate representation को JVM bytecode में कैसे map किया गया, इसके ideas और explanations किसी अधिक official implementation बनाने वाले के लिए मददगार हों, यही उम्मीद है। फिलहाल WASM GC support की कोई योजना नहीं है
    • GraalVM WASM executables चला सकता है: https://www.graalvm.org/latest/reference-manual/wasm/
    • यह 22 साल देर से CLR के कदमों पर चलने जैसा है
      “20 से ज्यादा programming tools vendors C++, Perl, Python, Java, COBOL, RPG, Haskell सहित लगभग 26 programming languages .NET पर उपलब्ध कराते हैं”
      स्रोत: https://news.microsoft.com/2001/10/22/massive-industry-and-d...
    • थोड़ा बारीकी से देखें तो JVM, garbage collectors से बड़ा concept है[^1]। हालांकि यह सही है कि JVM garbage collection की प्रयोगशाला रहा है
      ऐसा इसलिए नहीं कि academia JVM को लेकर असाधारण रूप से bold थी, बल्कि इसलिए कि JVM programs व्यापक रूप से इस्तेमाल हुए और अक्सर ऐसे तरीकों से इस्तेमाल हुए जिन्होंने किसी एक garbage collection technique पर दबाव डाला
      [^1]: https://www.baeldung.com/jvm-garbage-collectors. Azul JVM के पास भी अलग garbage collector है। ये सिर्फ वे हैं जिन्हें मैं जानता हूं, और काफी कुछ छूट भी गया होगा
    • सख्ती से कहें तो threads concurrency देते हैं, जरूरी नहीं कि parallelism दें। इसलिए इसे वास्तविक parallelism कहना अजीब लगता है
      शायद यह coroutines से तुलना में कहा गया होगा, लेकिन coroutines sequential होते हैं। execution order arbitrary हो सकता है, फिर भी आप इस बात पर निर्भर कर सकते हैं कि वे एक साथ execute नहीं होते
      अगर wasm threads अपनाता है, तो यह एक और अफसोसनाक “Worse is Better” स्थिति होगी। threads हमारे बनाए concurrency models में लगभग सबसे खराब हैं। बेशक concurrent COMEFROM जैसी चीजों को छोड़ दें

  • Julia WASM tools ऐसे apps बना सकते हैं जो इस feature को support करते हों या जिसकी जरूरत रखते हों। उदाहरण के लिए ODE solver को WASM में compile करने का उदाहरण https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp... पर है
    तुरंत काम करने के लिए Chrome v119 चाहिए, क्योंकि इसी version ने पहली बार garbage collection support enable किया था। WASM compiler के पहले page https://tshort.github.io/WebAssemblyCompiler.jl/stable/ पर और details हैं

    • यह वाकई बड़ा कदम है
      नए Memory{T} type की वजह से उम्मीद है कि और ज्यादा code compile किया जा सकेगा

  • “wasm नया LLVM है” जैसा अहसास होता है। जानना चाहता हूँ कि क्या और लोगों को भी ऐसा ही लगता है
    मैं समझता हूँ कि यह क्या करने की कोशिश कर रहा है, और इसकी ताकत दिखाने वाले demo भी देखे हैं, लेकिन ज़्यादातर चीज़ें अब भी तकनीकी तौर पर बहुत low-level हैं और असल में इस्तेमाल करने पर काफ़ी झंझट वाली हो जाती हैं
    जिज्ञासा है कि मौजूदा तरीके की जगह target के तौर पर इसे चुनने लायक, ज़्यादा व्यापक adoption के लिए यह कब तैयार माना जाएगा

    • LLVM virtual machine नहीं है, लेकिन WASM virtual machine है
      नाम की वजह से यह आम गलतफ़हमी होती है; LLVM की शुरुआत में virtual machine बनने की मंशा थी, लेकिन वह असल में कभी ऐसा नहीं रहा और आज भी नहीं है। homepage की पहली पंक्ति भी इसे साफ़ करती है: https://llvm.org/
      मूल रूप से यह C++ libraries का एक समूह है जो समय के साथ बदलने वाले intermediate representation को implement करता है, और compiler लिखने में मदद करने वाला tool है
      करीब 10 साल पहले Google में WASM जैसे क्षेत्र को निशाना बनाने वाला एक project था, और लगता है उन्होंने यही गलतफ़हमी पाल ली थी। वे LLVM को virtual machine मान बैठे थे। शायद वह PNaCl जैसा कुछ था
      यह थोड़ा वैसा है जैसे LuaJIT ने Lua को Lua 5.1 पर freeze कर दिया था। Lua कोई standard नहीं था, लेकिन reimplementation के लिए किसी खास version को freeze किया जा सकता है। हालांकि उस approach में एक साफ़ समस्या है: reimplement करने वालों को वे सारे bugs पता नहीं होते जिन्हें वे भी समय में साथ-साथ freeze कर रहे होते हैं
      WASM के “compromises” पर कभी-कभी भौंहें उठी हैं, लेकिन एक बात जिस पर शक नहीं किया जा सकता, वह यह है कि WASM सच में virtual machine है
      मैंने WASM GC की presentation देखी थी, और बनाने वालों ने trade-offs ईमानदारी से बताए। जैसे शुरुआत में runtime cast की ज़रूरत होगी, और measured overhead reasonable level पर है वगैरह। इस तरह का रवैया उल्टा भरोसा दिलाता है
      https://old.reddit.com/r/ProgrammingLanguages/comments/17crk...
    • मैं भी कुछ ऐसा ही सवाल पूछने आया था
      सच कहूँ तो wasm मुझे ठीक से समझ नहीं आता। हम असल में कौन-सी समस्या हल करने की कोशिश कर रहे हैं, यह साफ़ नहीं है
      सोचता हूँ कि लक्ष्य ऐसे languages में applications लिखना है जो JavaScript नहीं हैं या JavaScript में transpile नहीं होते। पता नहीं इसमें browser DOM display layer के साथ interaction वाला हिस्सा भी शामिल है या नहीं। मेरी समझ में असल में वह किया नहीं जा सकता, और अगर यह सही है, तो क्या लक्ष्य Flash की तरह DOM के भीतर किसी dedicated canvas में application चलाना है? अगर ऐसा है तो पता नहीं वह niche कितना बड़ा है
      एक और thread में Cloudflare Workers में wasm इस्तेमाल करने की बात भी थी। शायद इसलिए कि वह JavaScript interpreter के ज़रिए चलता है। लेकिन अगर लोग arbitrary runtime से Cloudflare Workers लिखना चाहते हैं, तो लगता है Cloudflare बस दूसरे runtimes का support जोड़ सकता है। उनके पास इतनी capability तो होगी ही
      या JavaScript ecosystem से connection के अलावा, क्या bytecode के रूप में wasm में कोई अपनी तरह की बेहतरीन खासियत है?
      ऐसा लगता है कि मैंने कोई introductory material miss कर दिया है जो समझाता हो कि यह technology दिलचस्प क्यों है, लेकिन इस point पर पूछना थोड़ा शर्मनाक लगता है
    • wasmtime जैसी चीज़ों को देखें तो आप मूल रूप से कई languages को support करने वाले बहुत सुरक्षित plugins वाला native program बना सकते हैं। इसी तरह browser में भी यह default security model बनाए रखते हुए चलता है
      LLVM काफ़ी coding किए बिना “by default आसान security sandbox” नहीं देता। wasmer में LLVM backend तो है, लेकिन निजी तौर पर मुझे यही WASM का सबसे बड़ा differentiator लगता है
    • “WASM नया LLVM है” के बजाय WASM नया JVM है कहना ज़्यादा सही है
    • “wasm नया Emscripten है” के ज़्यादा करीब है। यह सभी browsers में फैला हुआ कहीं ज़्यादा official standard है
      यह LLVM जैसी दिशा में तो जा रहा है, लेकिन अभी वहाँ से काफ़ी दूर है

  • चाहे यह कितना भी शानदार हो और कितनी भी संभावनाएँ खोलता हो, मैं बार-बार इस बात के बारे में सोचता हूँ कि आज के browsers बेहद complex हैं और खुद से बनाने की entry barrier लगभग असहनीय रूप से खड़ी है

    • खुद browser बनाने की curve सिर्फ़ बहुत steep नहीं, शाब्दिक रूप से असंभव है। पूरा operating system बनाना browser बनाने से कहीं आसान है
    • Google और Apple तक ने शुरुआत scratch से नहीं की; उन्होंने WebKit, यानी KDE KHTML का इस्तेमाल किया
    • खुद Linux बनाना भी असंभव है, लेकिन उस पर लोग शिकायत नहीं करते। Android को आसानी से खुद नहीं बनाया जा सकता, इसलिए उसे भी दोष नहीं देते
      दुनिया का सबसे सफल और accessible hypermedia platform आसानी से implement करने लायक क्यों होना चाहिए, यह समझ नहीं आता। स्वाभाविक है कि दुनिया का सबसे सफल online system complex और feature-rich होगा। इसी वजह से हम उसे इस्तेमाल करते हैं, और इसी वजह से वह जीता है
    • बात सही है, लेकिन यह काम पूरे browser engine के बिना चल सकने वाले ज़्यादा सरल alternative runtime की बुनियाद बनता है। V8 पर निर्भर Node या Deno के बारे में सोचिए
    • आधुनिक दुनिया की बहुत-सी चीज़ें पहले ही इस मुकाम पर पहुँच चुकी हैं। आप खुद car नहीं बना सकते, और घर भी पूरी तरह scratch से खुद बनाना practically असंभव है। building codes जैसी expert knowledge बहुत ज़्यादा चाहिए

  • यह बात प्रभावशाली है कि यह आखिरकार बना और रिलीज़ हुआ। WASM में GC जोड़ने की योजना कई सालों से सुन रहे थे, और पक्का नहीं था कि यह सच में होगा भी या नहीं
    मुझे उत्सुकता है कि WASM को target करने वाली उन भाषाओं में यह कितना मदद करेगा जहाँ runtime शामिल करने की वजह से बाइनरी बड़ी होने की समस्या होती है। जहाँ तक याद है, Blazor में सिर्फ hello world के लिए भी लगभग 1MB चाहिए था; पता नहीं WasmGC इसमें मदद करेगा या नहीं

    • WasmGC को .NET में उपयोगी बनने में समय लग सकता है। चर्चा के अनुसार, WasmGC के पहले version में कुछ .NET-विशेष scenarios को संभालने का अच्छा तरीका नहीं है, और उन scenarios को “post-post-mvp” के रूप में वर्गीकृत किया गया है [0]
      बेशक चिंता की बात यह है कि अगर कोई feature सिर्फ .NET को चाहिए, तो उसे जोड़ने की प्रेरणा बहुत ज्यादा नहीं होगी। उस स्थिति में, किसी खास GC version को cache करके दूसरे WASM assemblies द्वारा load किए जा सकने वाले include जैसे feature, भले ही दर्द पैदा करें, ज़्यादा उपयोगी हो सकते हैं
      [0] - https://github.com/WebAssembly/gc/issues/77
    • Chrome की Wasm team ने काम के दौरान data structures allocate करने वाले Fannkuch benchmark को C, Rust और Java में compile किया। C और Rust binaries compiler flags के हिसाब से 6.1K से 9.6K तक थीं, जबकि Java version 2.3K पर काफी छोटा था
      C और Rust garbage collector शामिल नहीं करते, लेकिन memory management के लिए उन्हें फिर भी malloc/free को साथ bundle करना पड़ता है। यहाँ Java छोटा इसलिए है क्योंकि उसे memory management code बिलकुल भी bundle करने की जरूरत नहीं है
      https://developer.chrome.com/blog/wasmgc/
      Blazor के मामले में, यह केवल GC में ही मदद करेगा। जहाँ तक याद है, Blazor को पूरा dotnet runtime साथ भेजना पड़ता है

  • Kotlin का नया wasm support काफी रोमांचक है। Compose Multiplatform का एक experimental version है जो browser को target कर सकता है, और यह WASM का इस्तेमाल करने वाला है
    Compose Multiplatform मूल रूप से Android के लिए Google Jetpack Compose में दूसरे platforms का support जोड़ता है
    कुछ दिन पहले तक iOS support alpha में था और अगले साल beta में जाने वाला है। Android और desktop support अब stable हो गए हैं। इनके stable होने पर, आप असल में लगभग किसी भी platform पर चलने वाली UI applications लिख सकते हैं
    wasm compiler Kotlin की अगली major release, Kotlin 2.0, के साथ release होने वाला है, जिसमें नया compiler k2 शामिल होगा। लगता है यह अगले साल की शुरुआत के आसपास संभव होगा। k2 अभी beta में उपलब्ध है और Kotlin 1.9.x में enable किया जा सकता है
    Kotlin multiplatform ecosystem की अच्छी बात यह है कि कई libraries पहले से ही कई platforms पर चलती हैं। इसलिए wasm compiler भी जल्दी ही इसका हिस्सा बन जाएगा और अच्छी libraries विरासत में ले लेगा। आम तौर पर build setup को उस ecosystem को target करने के लिए बदलना और missing platform-specific behavior implement करना ही काफी होगा
    इस क्षेत्र में एक और दिलचस्प बात अलग-अलग भाषाओं में लिखी libraries को इस्तेमाल करना और link करना है। उदाहरण के लिए, कई platform-specific हिस्से शायद पहले से मौजूद C या Rust libraries पर निर्भर होंगे। कई मामलों में ये वही libraries भी हो सकती हैं जिन्हें Kotlin Native इस्तेमाल करता है

    • मुझे उत्सुकता है कि web पर Compose Multiplatform कैसे काम करता है। क्या यह Flutter की तरह Canvas पर draw करता है?
      मुझे जानना है कि desktop, web, iOS और Android पर क्या वही widgets इस्तेमाल होते हैं। Android पर यह native है, यह समझ आता है। बाकी platforms पर क्या यह अलग-अलग styles की नकल करता है, पता नहीं। मुख्य सवाल यह है कि गैर-Android platforms पर Compose Multiplatform apps का feel कैसा होता है
      उदाहरण के लिए web पर Dart मुझे व्यक्तिगत रूप से बहुत stuttery लगता है, और desktop पर Electron भी वैसा ही। desktop पर Dart ठीक है, लेकिन apps में आम तौर पर buttons और spacing बड़े होते हैं, इसलिए वे असली native apps से ज्यादा emulator में चल रहे Android apps जैसे लगते हैं
      यह भी सोच रहा हूँ कि नए project के लिए Kotlin को भाषा के रूप में recommend किया जा सकता है या नहीं
    • जब भी try किया, Gradle की अव्यवस्था ने उत्साह ठंडा कर दिया

  • मुझे जानना है कि क्या कोई समझा सकता है कि यह blog post और Chrome announcement Go का ज़िक्र क्यों नहीं करते
    Go भी garbage collection का इस्तेमाल करता है, इसलिए ऐसा impression मिलता है कि उसे इस बदलाव का फायदा नहीं मिलेगा

    • WasmGC interior pointer (interior pointer) support नहीं करता, इसलिए Go के लिए फायदा उठाना मुश्किल है। कम से कम fat pointer जैसे भद्दे तरीके के बिना तो मुश्किल है

  • सोच रहा हूँ कि क्या runtime द्वारा C/C++/Rust के उपयोग के लिए built-in allocation library expose करना उचित होगा
    program अपनी allocation library bundle करने के बजाय उस library को चुन सकेगा

    • थोड़ी space बचाने वाले practical नज़रिए से यह उचित हो सकता है। लेकिन design के नज़रिए से, यह कोई “न्यूनतम आवश्यक feature” नहीं है जो पहले असंभव काम को संभव बनाता हो, इसलिए इसे standard का हिस्सा बनाने पर यह बिना वजह bloated हो जाएगा
      Wasm GC primitives को इस तरह design किया गया था कि जितना संभव हो उतने छोटे additions से सबसे बड़ा improvement मिले। SIMD जैसे दूसरे primitives जोड़े जाते समय भी ऐसा इसलिए होता है क्योंकि वे उस capability को हासिल करने के लिए “लगभग न्यूनतम primitives” होते हैं। यहाँ हमें जितना संभव हो उतने छोटे building blocks चाहिए
      लेकिन malloc/free जैसा memory allocator API न्यूनतम feature नहीं है। memory allocator असल में policies और design decisions का bundle होता है, और algorithm उसी से निकलता है। उस क्षेत्र का basic building block “allocator के स्वामित्व वाला linear memory का हिस्सा” है, और वह linear memory WASM के पास पहले दिन से मौजूद है
      अलग-अलग runtime इसे provide करें, यह उचित हो सकता है। उदाहरण के लिए built-in wasm import को linear memory का कुछ हिस्सा pass करके runtime-implemented allocator से handle कराना। लेकिन मुझे लगता है कि इसके standardize होने की संभावना बहुत कम है। साथ ही GC के बिना Wasm languages के लिए ज़्यादातर tools मौजूदा codebase और उनके allocators को port करने के तरीके के अनुसार बने हैं। आखिरकार, one-off implementation के लिए maintain करने वाला code बढ़ेगा, इसलिए लगाया गया effort शायद उतना worthwhile न हो
    • उस approach की मुश्किल यह है कि allocation library का behavior standardized और deterministic होना चाहिए
      अगर deterministic न हो, तो program behavior के differences महत्वपूर्ण हो सकते हैं। उदाहरण के लिए, अगर कोई browser memory को बेहतर reuse करने वाला “smart” allocator डालता है, तो जो program दूसरे browser में linear memory fragmentation के कारण out of memory हो जाता है, वह उस browser में succeed कर सकता है। browsers ने historically ऐसे differences से बचने के लिए behavior standardization पर बहुत मेहनत की है
      malloc/free implementation के behavior को standardize करना भी कई वजहों से tricky है। पहला, free list को कैसे handle किया जाए, कौन-से chunk sizes इस्तेमाल किए जाएँ आदि में complexity बहुत है। spec में डालने के लिए यह बहुत ज्यादा है। दूसरा, किसी specific behavior को standardize करने पर उसे improve नहीं किया जा सकेगा, जबकि बेहतर malloc/free ideas आज भी आ रहे हैं
      इन कारणों से मैं इसके wasm spec में शामिल होने की संभावना को लेकर skeptical हूँ
      इसके उलट GC इन समस्याओं से बचता है। pointer values observable नहीं होतीं, इसलिए specify करने के लिए कुछ नहीं होता
    • यह एक smart direction जैसा लगता है। alloc और related functions को runtime functions के रूप में जोड़ दें ताकि traditional code उन्हें call करे, और कोई भी GC उसके ऊपर build किया जा सके

  • इस दिशा को लेकर मैं थोड़ा skepticial हूँ। यह WebAssembly की complexity को काफी बढ़ा रहा है
    Garbage collector एक leaky abstraction है। कुछ internal pointers को support करते हैं और कुछ नहीं। कुछ memory share करने वाले parallel tasks को support करते हैं और कुछ नहीं। कुछ को compaction चाहिए, जिससे C FFI और कठिन हो जाता है, और कुछ को नहीं। कुछ को green processes/threads और growable stacks में इस्तेमाल होने वाले mechanisms के साथ गहराई से integrate होना पड़ता है, और कुछ को नहीं
    Erlang, JavaScript, Python, Go जैसी languages को देखें तो language-level choices किसी हद तक garbage collector में reflect होती हैं
    कई languages को support करने वाली general-purpose/सामान्य virtual machine का idea JVM, CLR, Parrot आदि के रूप में कई बार आजमाया गया है, और सफलता सीमित रही है। सोच रहा हूँ कि इस बार क्या अलग है

    • इस बार अलग बात यह है कि WASM ने Sun JVM और Microsoft CLR ने जिस तरीके की कोशिश की थी, उसके timeline को उलट दिया है
      JVM/CLR ने पहले virtual machine, intermediate language instruction spec और runtime बनाया, और फिर उसे जितना संभव हो उतना widely distribute करके universal client adoption की उम्मीद की। यानी उम्मीद यह थी कि “intermediate language VM” इतनी आकर्षक होगी कि पूरी industry में फैल जाएगी। यह उम्मीद केवल आंशिक रूप से सही निकली। JVM/CLR desktop और server पर फैले, लेकिन web browsers में Java Applet और Microsoft Silverlight fail हुए, और mobile platforms पर भी widely adopted नहीं हुए
      WASM का क्रम उल्टा है। यह उस चीज़ से उल्टी दिशा में शुरू करता है जो पहले से industry-wide deployed और adopted है, यानी JavaScript, और उससे “virtual machine, intermediate language instruction spec, runtime” बनाता है
      इस नज़रिए से JavaScript नाम की तथाकथित “toy language” सभी clients पर पहले widely deploy होने के लिए 20 साल का Trojan horse थी। अब industry जैसे कह रही है, “क्या किसी ने notice किया कि server+desktop+browser+mobile पर universal runtime JavaScript पहले से मौजूद है? चलो intermediate language runtime बनाकर इसे तेज़ करते हैं”
      कुछ technical problems भी थीं। Sun JVM में raw pointers नहीं थे, इसलिए C/C++ जैसी pointer-based languages के लिए अच्छा performance target बनना कठिन था, और MS CLR macOS पर उपलब्ध नहीं था। Silverlight का minimal CLR अपवाद है। लेकिन इन technical limitations से ज्यादा explanatory power इस बात में है कि JavaScript harmless Trojan horse की तरह किस timeline में deployed हुई
    • JVM और CLR को कई languages support करने के लिए design किया गया कहना मुश्किल है। JVM की एक host language Java है, और JVM पर चलना चाहने वाली दूसरी languages Java type system से जितनी दूर जाती हैं, उतना बड़ा बोझ उठाती हैं
      Wasm ऊपर दिए गए bytecode formats में से अधिकतर से ज्यादा low-level है। Statically typed structs और arrays जोड़ने वाले Wasm GC, और typed functions लाने वाले function-references proposal को शामिल करने पर भी ऐसा ही है। Wasm GC में tagged pointer i31ref के लिए explicit support भी है
      इन्हीं वजहों से Wasm GC, ज्यादा low-level होने के कारण, ऊपर बताए गए प्रयासों से अधिक general है
    • WASM-GC support को जानबूझकर जितना संभव हो उतना simple रखा गया है। https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... देखें
      कई languages को समान और seamless तरीके से support करने वाली “universal” या “general” VM बनाना WASM-GC का explicit goal नहीं है। माना जाता है कि हर implementation को WASM द्वारा दी गई basic support के ऊपर अपनी hacks और special semantics चाहिए हो सकती हैं, और FFI व languages के बीच interoperability को पूरी तरह अलग problem माना जाता है, इसलिए यह acceptable है
    • मेरे हिसाब से फर्क इस project की importance का है
      JavaScript garbage collection बनी रहेगी, और बताए गए examples में यह सबसे ज्यादा टिकाऊ तरीके से जमी हुई लगती है
      कई मामलों में भले ही यह inferior हो, दूसरी languages और applications/libraries को इसके हिसाब से adapt करना होगा
    • wasm जो कर रहा है वह पिछले प्रयासों से अलग है। GC feature दूसरी languages के साथ interoperability या language runtime implementations के बीच development resources share करने के लिए नहीं दिया जा रहा है
      wasm GC feature इसलिए देता है ताकि managed-memory runtime languages, limited memory model की सीमाओं से परेशान हुए बिना wasm environment को target कर सकें, और secondary benefit के तौर पर bundle size घट सके
      wasm संभवतः ऐसे अधिक tunable GC parameters support कर सकता है जो guest language की characteristics से बेहतर match करें। साथ ही, जिन general-purpose language runtimes से इसकी तुलना की जा रही है, उनके उलट language implementers के पास custom runtime बनाने का विकल्प बिल्कुल नहीं है

  • मौजूदा WASM GC की व्यवहार्यता को लेकर कई चिंताओं पर यहाँ चर्चा की गई है। अंग्रेज़ी Google अनुवाद:
    https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl...
    मूल लेख:
    https://habr.com/ru/articles/757182/
    यह TeaVM के लेखक का लेख है, जो 10 साल से Java और JVM code को browser में कुशलता से चलाने पर काम कर रहे हैं। https://teavm.org/
    TeaVM का मौजूदा Java-to-JavaScript रूपांतरण browser के JS GC का इस्तेमाल करते हुए भी अच्छी performance देता है। यह देखना दिलचस्प होगा कि WASM GC और mature होकर उससे भी तेज़ हो पाएगा या नहीं

    • दिलचस्प लेख है।
      लेख में उठाई गई समस्याओं पर कुछ notes: manual shadow stack की ज़रूरत वाली समस्या WasmGC में हल हो जाती है। लिंक में बताए गए तरीके की तरह, यह JS में चलने वाले तरीके जैसा ही है।
      try-catch की कमी Wasm exception handling proposal से हल हो चुकी है, जो browser में पहले ही ship हो चुका है: https://github.com/WebAssembly/exception-handling/blob/main/...
      null checks भी ज़्यादातर WasmGC से हल हो जाते हैं। specification non-nullable local types define करता है, और VM लेख में बताई गई technique की तरह signals का इस्तेमाल करके optimize कर सकता है। उदाहरण के लिए Wizard ऐसा करता है।
      class initialization, जैसा लेख में कहा गया है, एक कठिन समस्या है। J2Wasm और Binaryen toolchain-level static analysis के ज़रिए इसे optimize करने पर काम कर रहे हैं। हाल में मेरे द्वारा लिखा गया PR इस दिशा में आगे बढ़ा है: https://github.com/WebAssembly/binaryen/pull/6061
      लेख में जिस vtable overhead का ज़िक्र है, वह समस्या बन सकता है। हालांकि इसके अच्छे measurements अभी पता नहीं हैं। method dispatch के लिए post-MVP solutions के कुछ ideas हैं, लेकिन अभी कुछ ठोस नहीं है।
      null checks और traps के बारे में, trap के बजाय exception throw करने वाले GC instruction variants पर चर्चा हुई थी। लेकिन measurements में अभी यह बड़ी समस्या के रूप में सामने नहीं आया है, इसलिए इसकी priority कम है।
      लेखक ने stack walking, signals और memory control को महत्वपूर्ण areas बताया है, और यह सही है।
      कुल मिलाकर WasmGC और exception handling की वजह से, आज J2Wasm जो Java output करता है वह काफ़ी अच्छी स्थिति में है। आम तौर पर यह Java को JavaScript में compile करने वाले J2CL से तेज़ है। फिर भी सुधार की गुंजाइश निश्चित रूप से है।