WebAssembly GC: พรมแดนใหม่สำหรับเว็บแอปพลิเคชันประสิทธิภาพสูง

WebAssembly (Wasm) ถือกำเนิดขึ้นพร้อมกับคำมั่นสัญญาที่ยิ่งใหญ่ นั่นคือการนำประสิทธิภาพที่ใกล้เคียงกับเนทีฟมาสู่เว็บ สร้างเป้าหมายการคอมไพล์ที่เป็นสากลสำหรับภาษาโปรแกรมมิ่งจำนวนมาก สำหรับนักพัฒนาที่ทำงานกับภาษาระบบ (systems languages) เช่น C++, C และ Rust คำสัญญานี้ก็เป็นจริงได้อย่างรวดเร็ว ภาษาเหล่านี้ให้การควบคุมหน่วยความจำที่ละเอียด ซึ่งสอดคล้องกับโมเดลหน่วยความจำเชิงเส้น (linear memory model) ที่เรียบง่ายแต่ทรงพลังของ Wasm ได้เป็นอย่างดี อย่างไรก็ตาม สำหรับนักพัฒนาส่วนใหญ่ทั่วโลก—ผู้ที่ใช้ภาษาระดับสูงที่มีการจัดการหน่วยความจำ (managed languages) เช่น Java, C#, Kotlin, Go และ Dart—เส้นทางสู่ WebAssembly นั้นเต็มไปด้วยความท้าทาย

ปัญหาหลักคือการจัดการหน่วยความจำมาโดยตลอด ภาษาเหล่านี้อาศัยตัวเก็บขยะ (garbage collector หรือ GC) เพื่อเรียกคืนหน่วยความจำที่ไม่ได้ใช้งานแล้วโดยอัตโนมัติ ทำให้นักพัฒนาไม่ต้องเผชิญกับความซับซ้อนของการจัดสรรและคืนค่าหน่วยความจำด้วยตนเอง ในอดีต การผสานโมเดลนี้เข้ากับหน่วยความจำเชิงเส้นที่แยกเป็นอิสระของ Wasm จำเป็นต้องใช้วิธีแก้ปัญหาที่ยุ่งยาก ส่งผลให้ไบนารีมีขนาดใหญ่ เกิดปัญหาคอขวดด้านประสิทธิภาพ และต้องใช้ 'glue code' ที่ซับซ้อน

ขอแนะนำ WebAssembly GC (WasmGC) ชุดข้อเสนอที่พลิกโฉมวงการนี้ไม่ใช่แค่การอัปเดตเล็กน้อย แต่เป็นการเปลี่ยนแปลงกระบวนทัศน์ที่กำหนดนิยามใหม่โดยสิ้นเชิงว่า managed languages ทำงานบนเว็บอย่างไร WasmGC นำเสนอระบบ garbage collection ชั้นหนึ่งที่มีประสิทธิภาพสูงเข้ามาในมาตรฐาน Wasm โดยตรง ทำให้สามารถผสานรวม managed languages เข้ากับแพลตฟอร์มเว็บได้อย่างราบรื่น มีประสิทธิภาพ และโดยตรง ในคู่มือฉบับสมบูรณ์นี้ เราจะสำรวจว่า WasmGC คืออะไร ปัญหาที่มันแก้ไข วิธีการทำงาน และเหตุใดมันจึงเป็นอนาคตสำหรับเว็บแอปพลิเคชันยุคใหม่ที่ทรงพลังและซับซ้อน

ความท้าทายด้านหน่วยความจำใน WebAssembly แบบดั้งเดิม

เพื่อให้เข้าใจถึงความสำคัญของ WasmGC อย่างถ่องแท้ เราต้องเข้าใจข้อจำกัดที่มันเข้ามาแก้ไขก่อน ข้อกำหนดดั้งเดิมของ WebAssembly MVP (Minimum Viable Product) มีโมเดลหน่วยความจำที่เรียบง่ายอย่างน่าทึ่ง นั่นคือกลุ่มหน่วยความจำขนาดใหญ่ที่ต่อเนื่องและแยกเป็นอิสระเรียกว่า linear memory

ลองนึกภาพว่ามันเป็นอาร์เรย์ของไบต์ขนาดใหญ่ที่โมดูล Wasm สามารถอ่านและเขียนได้อย่างอิสระ โฮสต์ JavaScript ก็สามารถเข้าถึงหน่วยความจำนี้ได้เช่นกัน แต่ทำได้เพียงอ่านและเขียนเป็นส่วนๆ เท่านั้น โมเดลนี้รวดเร็วและปลอดภัยอย่างเหลือเชื่อ เนื่องจากโมดูล Wasm ถูกจำกัดอยู่ในพื้นที่หน่วยความจำของตัวเอง (sandboxed) ซึ่งเหมาะอย่างยิ่งสำหรับภาษาอย่าง C++ และ Rust ที่ออกแบบมาโดยมีแนวคิดในการจัดการหน่วยความจำผ่านพอยน์เตอร์ (ซึ่งใน Wasm จะแสดงเป็นค่าออฟเซ็ตจำนวนเต็มในอาร์เรย์หน่วยความจำเชิงเส้นนี้)

ภาระของ 'Glue Code'

ปัญหาเกิดขึ้นเมื่อคุณต้องการส่งผ่านโครงสร้างข้อมูลที่ซับซ้อนระหว่าง JavaScript และ Wasm เนื่องจากหน่วยความจำเชิงเส้นของ Wasm เข้าใจเพียงตัวเลข (จำนวนเต็มและทศนิยม) คุณจึงไม่สามารถส่งผ่านอ็อบเจ็กต์ JavaScript ไปยังฟังก์ชัน Wasm ได้โดยตรง แต่คุณต้องทำกระบวนการแปลงที่สิ้นเปลืองทรัพยากร:

• Serialization: อ็อบเจ็กต์ JavaScript จะถูกแปลงเป็นรูปแบบที่ Wasm สามารถเข้าใจได้ โดยทั่วไปคือสตรีมไบต์เช่น JSON หรือรูปแบบไบนารีเช่น Protocol Buffers
• Memory Copying: ข้อมูลที่ถูกแปลงแล้วนี้จะถูกคัดลอกไปยังหน่วยความจำเชิงเส้นของโมดูล Wasm
• Wasm Processing: โมดูล Wasm จะได้รับพอยน์เตอร์ (ค่าออฟเซ็ตจำนวนเต็ม) ที่ชี้ไปยังตำแหน่งของข้อมูลในหน่วยความจำเชิงเส้น จากนั้นจะแปลงข้อมูลกลับเป็นโครงสร้างข้อมูลภายในของตนเอง แล้วจึงประมวลผล
• Reverse Process: หากต้องการส่งคืนผลลัพธ์ที่ซับซ้อน ก็ต้องทำกระบวนการทั้งหมดนี้ย้อนกลับ

กระบวนการทั้งหมดนี้ถูกจัดการโดย 'glue code' ซึ่งมักจะสร้างขึ้นโดยอัตโนมัติจากเครื่องมืออย่าง `wasm-bindgen` สำหรับ Rust หรือ Emscripten สำหรับ C++ แม้ว่าเครื่องมือเหล่านี้จะเป็นความมหัศจรรย์ทางวิศวกรรม แต่ก็ไม่สามารถขจัดภาระโดยธรรมชาติของการแปลงข้อมูลไปมา (serialization/deserialization) และการคัดลอกหน่วยความจำที่เกิดขึ้นตลอดเวลาได้ ภาระนี้ ซึ่งมักเรียกว่า 'JS/Wasm boundary cost' อาจลบล้างประโยชน์ด้านประสิทธิภาพหลายอย่างของการใช้ Wasm ไปเลยสำหรับแอปพลิเคชันที่มีการโต้ตอบกับโฮสต์บ่อยครั้ง

ภาระของ GC ที่ทำงานในตัวเอง

สำหรับ managed languages ปัญหานั้นลึกซึ้งยิ่งกว่า คุณจะรันภาษาที่ต้องใช้ garbage collector ในสภาพแวดล้อมที่ไม่มีได้อย่างไร? วิธีแก้ปัญหาหลักคือการคอมไพล์ runtime ทั้งหมดของภาษานั้น รวมถึง garbage collector ของมันเอง เข้าไปในโมดูล Wasm ด้วย จากนั้น GC จะจัดการฮีปของตัวเอง ซึ่งเป็นเพียงพื้นที่ขนาดใหญ่ที่จัดสรรไว้ภายในหน่วยความจำเชิงเส้นของ Wasm

แนวทางนี้มีข้อเสียที่สำคัญหลายประการ:

• ขนาดไบนารีที่ใหญ่มาก: การรวม GC และ runtime ของภาษาเข้าไปด้วยอาจเพิ่มขนาดไฟล์ `.wasm` ได้หลายเมกะไบต์ สำหรับเว็บแอปพลิเคชันที่เวลาโหลดเริ่มต้นมีความสำคัญอย่างยิ่ง สิ่งนี้มักจะเป็นเรื่องที่ยอมรับไม่ได้
• ปัญหาด้านประสิทธิภาพ: GC ที่รวมเข้าไปด้วยนั้นไม่รู้จัก GC ของสภาพแวดล้อมโฮสต์ (เช่น ของเบราว์เซอร์) ระบบทั้งสองทำงานเป็นอิสระต่อกัน ซึ่งอาจนำไปสู่ความไร้ประสิทธิภาพ JavaScript GC ของเบราว์เซอร์เป็นเทคโนโลยีที่ได้รับการปรับแต่งมาอย่างดี เป็นแบบ generational และ concurrent ซึ่งพัฒนามานานหลายทศวรรษ GC ที่คอมไพล์มาเพื่อ Wasm โดยเฉพาะจึงยากที่จะแข่งขันกับความซับซ้อนในระดับนั้นได้
• หน่วยความจำรั่ว (Memory Leaks): มันสร้างสถานการณ์การจัดการหน่วยความจำที่ซับซ้อน โดยที่ GC ของเบราว์เซอร์จัดการอ็อบเจ็กต์ JavaScript และ GC ของโมดูล Wasm จัดการอ็อบเจ็กต์ภายในของตัวเอง การเชื่อมต่อทั้งสองระบบโดยไม่ทำให้หน่วยความจำรั่วไหลนั้นเป็นเรื่องที่ยากมาก

ขอแนะนำ WebAssembly GC: การเปลี่ยนแปลงกระบวนทัศน์

WebAssembly GC จัดการกับความท้าทายเหล่านี้โดยตรงโดยการขยายมาตรฐานหลักของ Wasm ด้วยความสามารถใหม่ๆ ในการจัดการหน่วยความจำ แทนที่จะบังคับให้โมดูล Wasm ต้องจัดการทุกอย่างภายในหน่วยความจำเชิงเส้น WasmGC ช่วยให้โมดูลสามารถเข้าร่วมในระบบนิเวศ garbage collection ของโฮสต์ได้โดยตรง

ข้อเสนอนี้นำเสนอแนวคิดหลักสองประการ: Reference Types และ Managed Data Structures (Structs และ Arrays)

Reference Types: สะพานเชื่อมสู่โฮสต์

Reference Types ช่วยให้โมดูล Wasm สามารถถือ reference ไปยังอ็อบเจ็กต์ที่จัดการโดยโฮสต์ได้โดยตรงและไม่สามารถตรวจสอบภายในได้ (opaque) สิ่งที่สำคัญที่สุดคือ `externref` (external reference) โดย `externref` นั้นเปรียบเสมือน 'ตัวชี้' ที่ปลอดภัยไปยังอ็อบเจ็กต์ JavaScript (หรืออ็อบเจ็กต์โฮสต์อื่นๆ เช่น DOM node, Web API เป็นต้น)

ด้วย `externref` คุณสามารถส่งผ่านอ็อบเจ็กต์ JavaScript เข้าไปยังฟังก์ชัน Wasm ด้วย reference ได้ โมดูล Wasm จะไม่รู้โครงสร้างภายในของอ็อบเจ็กต์ แต่สามารถเก็บ reference นั้นไว้ จัดเก็บ และส่งกลับไปยัง JavaScript หรือไปยัง API อื่นๆ ของโฮสต์ได้ ซึ่งช่วยขจัดความจำเป็นในการทำ serialization สำหรับสถานการณ์การทำงานร่วมกันหลายๆ อย่างได้อย่างสมบูรณ์ มันคือความแตกต่างระหว่างการส่งพิมพ์เขียวของรถยนต์อย่างละเอียด (serialization) กับการยื่นกุญแจรถให้ (reference)

Structs และ Arrays: ข้อมูลที่ถูกจัดการบนฮีปเดียวกัน

ในขณะที่ `externref` เป็นการปฏิวัติสำหรับการทำงานร่วมกับโฮสต์ ส่วนที่สองของ WasmGC นั้นทรงพลังยิ่งกว่าสำหรับการนำไปใช้กับภาษาต่างๆ WasmGC กำหนดโครงสร้างประเภทข้อมูลระดับสูงใหม่ใน WebAssembly โดยตรง: `struct` (กลุ่มของฟิลด์ที่มีชื่อ) และ `array` (ลำดับขององค์ประกอบ)

ที่สำคัญคือ อินสแตนซ์ของ structs และ arrays เหล่านี้ ไม่ได้ ถูกจัดสรรใน linear memory ของโมดูล Wasm แต่จะถูกจัดสรรบนฮีปที่ใช้ร่วมกันและมีการจัดการขยะ (garbage-collected heap) ซึ่งจัดการโดยสภาพแวดล้อมของโฮสต์ (เอนจิน V8, SpiderMonkey หรือ JavaScriptCore ของเบราว์เซอร์)

นี่คือนวัตกรรมหลักของ WasmGC ตอนนี้โมดูล Wasm สามารถสร้างข้อมูลที่มีโครงสร้างซับซ้อนที่โฮสต์ GC เข้าใจได้โดยกำเนิด ผลลัพธ์ที่ได้คือ ฮีปที่เป็นหนึ่งเดียว (unified heap) ที่อ็อบเจ็กต์ JavaScript และอ็อบเจ็กต์ Wasm สามารถอยู่ร่วมกันและอ้างอิงถึงกันได้อย่างราบรื่น

WebAssembly GC ทำงานอย่างไร: เจาะลึกยิ่งขึ้น

เรามาดูรายละเอียดกลไกของโมเดลใหม่นี้กัน เมื่อภาษาอย่าง Kotlin หรือ Dart ถูกคอมไพล์ไปยัง WasmGC มันจะกำหนดเป้าหมายไปที่ชุดคำสั่ง Wasm ใหม่สำหรับการจัดการหน่วยความจำ

• การจัดสรรหน่วยความจำ: แทนที่จะเรียกใช้ `malloc` เพื่อจองพื้นที่ใน linear memory คอมไพเลอร์จะสร้างคำสั่งเช่น `struct.new` หรือ `array.new` เอนจิน Wasm จะดักจับคำสั่งเหล่านี้และทำการจัดสรรหน่วยความจำบน GC heap
• การเข้าถึงฟิลด์: คำสั่งเช่น `struct.get` และ `struct.set` ถูกใช้เพื่อเข้าถึงฟิลด์ของอ็อบเจ็กต์ที่ถูกจัดการเหล่านี้ เอนจินจะจัดการการเข้าถึงหน่วยความจำอย่างปลอดภัยและมีประสิทธิภาพ
• Garbage Collection: โมดูล Wasm ไม่จำเป็นต้องมี GC ของตัวเอง เมื่อโฮสต์ GC ทำงาน มันจะสามารถเห็นกราฟทั้งหมดของ object references ไม่ว่าจะมาจาก JavaScript หรือ Wasm ก็ตาม หากอ็อบเจ็กต์ที่จัดสรรโดย Wasm ไม่ได้ถูกอ้างอิงจากทั้งโมดูล Wasm หรือโฮสต์ JavaScript แล้ว โฮสต์ GC จะเรียกคืนหน่วยความจำนั้นโดยอัตโนมัติ

เรื่องเล่าของสองฮีปที่รวมเป็นหนึ่ง

โมเดลเก่าบังคับให้มีการแบ่งแยกที่เข้มงวด: ฮีปของ JS และฮีปของ linear memory ใน Wasm ด้วย WasmGC กำแพงนี้ได้ถูกทลายลง อ็อบเจ็กต์ JavaScript สามารถถือ reference ไปยัง struct ของ Wasm และ struct ของ Wasm นั้นก็สามารถถือ reference ไปยังอ็อบเจ็กต์ JavaScript อื่นได้ garbage collector ของโฮสต์สามารถสำรวจกราฟทั้งหมดนี้ได้ ทำให้มีการจัดการหน่วยความจำที่เป็นหนึ่งเดียวและมีประสิทธิภาพสำหรับทั้งแอปพลิเคชัน

การผสานรวมอย่างลึกซึ้งนี้เองที่ทำให้ภาษาต่างๆ สามารถละทิ้ง runtime และ GC ของตนเองได้ ตอนนี้พวกเขาสามารถพึ่งพา GC ที่ทรงพลังและได้รับการปรับแต่งมาอย่างดีซึ่งมีอยู่แล้วในทุกเว็บเบราว์เซอร์สมัยใหม่

ประโยชน์ที่จับต้องได้ของ WasmGC สำหรับนักพัฒนาทั่วโลก

ข้อดีทางทฤษฎีของ WasmGC แปรเปลี่ยนเป็นประโยชน์ที่จับต้องได้และเปลี่ยนแปลงวงการสำหรับนักพัฒนาและผู้ใช้ปลายทางทั่วโลก

1. ลดขนาดไบนารีลงอย่างมาก

นี่คือประโยชน์ที่เห็นได้ชัดเจนที่สุดในทันที การที่ไม่ต้องรวม runtime การจัดการหน่วยความจำและ GC ของภาษาเข้าไปด้วย ทำให้โมดูล Wasm มีขนาดเล็กลงอย่างมาก การทดลองในช่วงแรกจากทีมงานของ Google และ JetBrains ได้แสดงผลลัพธ์ที่น่าทึ่ง:

• แอปพลิเคชัน 'Hello, World' ของ Kotlin/Wasm ที่เรียบง่าย ซึ่งก่อนหน้านี้มีขนาดหลายเมกะไบต์ (MB) เมื่อรวม runtime ของตัวเองเข้าไปด้วย จะลดขนาดลงเหลือเพียงไม่กี่ร้อยกิโลไบต์ (KB) เมื่อใช้ WasmGC
• เว็บแอปพลิเคชันของ Flutter (Dart) พบว่าขนาดโค้ดที่คอมไพล์แล้วลดลงกว่า 30% เมื่อเปลี่ยนมาใช้คอมไพเลอร์ที่ใช้ WasmGC

สำหรับผู้ชมทั่วโลกที่ความเร็วอินเทอร์เน็ตอาจแตกต่างกันอย่างมาก ขนาดดาวน์โหลดที่เล็กลงหมายถึงเวลาในการโหลดแอปพลิเคชันที่เร็วขึ้น ค่าใช้จ่ายดาต้าที่ต่ำลง และประสบการณ์ผู้ใช้ที่ดีขึ้นมาก

2. ประสิทธิภาพที่ดีขึ้นอย่างมหาศาล

ประสิทธิภาพที่เพิ่มขึ้นมาจากหลายแหล่ง:

• การเริ่มต้นที่เร็วขึ้น: ไบนารีขนาดเล็กไม่เพียงแต่ดาวน์โหลดได้เร็วขึ้น แต่ยังทำให้เอนจินของเบราว์เซอร์สามารถแยกวิเคราะห์ คอมไพล์ และสร้างอินสแตนซ์ได้เร็วขึ้นด้วย
• การทำงานร่วมกันที่ไม่มีค่าใช้จ่าย: ขั้นตอนการทำ serialization และการคัดลอกหน่วยความจำที่สิ้นเปลืองที่รอยต่อระหว่าง JS/Wasm จะถูกกำจัดออกไปเป็นส่วนใหญ่ การส่งผ่านอ็อบเจ็กต์ระหว่างสองฝั่งจึงมีค่าใช้จ่ายน้อยพอๆ กับการส่งผ่านพอยน์เตอร์ นี่เป็นชัยชนะครั้งใหญ่สำหรับแอปพลิเคชันที่สื่อสารกับ API ของเบราว์เซอร์หรือไลบรารี JS บ่อยครั้ง
• GC ที่มีประสิทธิภาพและพัฒนามาอย่างดี: เอนจิน GC ของเบราว์เซอร์เป็นผลงานชิ้นเอกทางวิศวกรรม มันเป็นแบบ generational, incremental และมักจะเป็นแบบ concurrent ซึ่งหมายความว่ามันสามารถทำงานได้โดยมีผลกระทบต่อเธรดหลักของแอปพลิเคชันน้อยที่สุด ป้องกันการกระตุกและ 'jank' แอปพลิเคชันที่ใช้ WasmGC จะได้ใช้ประโยชน์จากเทคโนโลยีระดับโลกนี้ฟรี

3. ประสบการณ์นักพัฒนาที่เรียบง่ายและทรงพลังยิ่งขึ้น

WasmGC ทำให้การพัฒนาเว็บด้วย managed languages เป็นเรื่องที่เป็นธรรมชาติและสะดวกสบาย

• Glue Code น้อยลง: นักพัฒนาใช้เวลาน้อยลงในการเขียนและดีบักโค้ด interop ที่ซับซ้อนซึ่งจำเป็นสำหรับการส่งข้อมูลไปมาระหว่าง Wasm
• การจัดการ DOM โดยตรง: ด้วย `externref` ตอนนี้โมดูล Wasm สามารถถือ reference ไปยังองค์ประกอบ DOM ได้โดยตรง ซึ่งเปิดประตูให้เฟรมเวิร์ก UI ประสิทธิภาพสูงที่เขียนด้วยภาษาอย่าง C# หรือ Kotlin สามารถจัดการ DOM ได้อย่างมีประสิทธิภาพเทียบเท่ากับเฟรมเวิร์ก JavaScript แบบเนทีฟ
• การย้ายโค้ดที่ง่ายขึ้น: การนำโค้ดเบสที่มีอยู่ของเดสก์ท็อปหรือฝั่งเซิร์ฟเวอร์ที่เขียนด้วย Java, C# หรือ Go มาคอมไพล์ใหม่สำหรับเว็บจะตรงไปตรงมามากขึ้น เนื่องจากโมเดลการจัดการหน่วยความจำหลักยังคงสอดคล้องกัน

ผลกระทบในทางปฏิบัติและเส้นทางข้างหน้า

WasmGC ไม่ใช่ความฝันที่ห่างไกลอีกต่อไป มันคือความจริง ณ ปลายปี 2023 มันถูกเปิดใช้งานโดยค่าเริ่มต้นใน Google Chrome (เอนจิน V8) และ Mozilla Firefox (SpiderMonkey) ส่วน Safari ของ Apple (JavaScriptCore) ก็กำลังอยู่ในระหว่างการพัฒนา การสนับสนุนอย่างกว้างขวางจากผู้จำหน่ายเบราว์เซอร์รายใหญ่เหล่านี้เป็นสัญญาณว่า WasmGC คืออนาคต

การนำไปใช้ในภาษาและเฟรมเวิร์ก

ระบบนิเวศกำลังยอมรับความสามารถใหม่อย่างรวดเร็ว:

• Kotlin/Wasm: JetBrains เป็นผู้สนับสนุนรายใหญ่ และ Kotlin เป็นหนึ่งในภาษาแรกๆ ที่มีการสนับสนุนเป้าหมาย WasmGC ที่สมบูรณ์และพร้อมใช้งานจริง
• Dart & Flutter: ทีม Flutter ที่ Google กำลังใช้งาน WasmGC อย่างจริงจังเพื่อนำแอปพลิเคชัน Flutter ประสิทธิภาพสูงมาสู่เว็บ โดยเปลี่ยนจากกลยุทธ์การคอมไพล์ที่ใช้ JavaScript ก่อนหน้านี้
• Java & TeaVM: โครงการ TeaVM ซึ่งเป็นคอมไพเลอร์ ahead-of-time สำหรับ Java bytecode ได้รองรับเป้าหมาย WasmGC แล้ว ทำให้แอปพลิเคชัน Java สามารถทำงานได้อย่างมีประสิทธิภาพในเบราว์เซอร์
• C# & Blazor: ในขณะที่ Blazor แต่เดิมใช้ .NET runtime ที่คอมไพล์ไปยัง Wasm (พร้อมกับ GC ของตัวเอง) ทีมงานกำลังสำรวจ WasmGC อย่างจริงจังเพื่อเป็นแนวทางในการปรับปรุงประสิทธิภาพและลดขนาด payload อย่างมาก
• Go: คอมไพเลอร์ Go อย่างเป็นทางการกำลังเพิ่มเป้าหมายที่ใช้ WasmGC (`-target=wasip1/wasm-gc`)

หมายเหตุสำคัญสำหรับนักพัฒนา C++ และ Rust: WasmGC เป็นฟีเจอร์ที่เพิ่มเติมเข้ามา มันไม่ได้มาแทนที่หรือยกเลิกการใช้งาน linear memory ภาษาที่จัดการหน่วยความจำด้วยตนเองสามารถและจะยังคงใช้ linear memory ต่อไปเหมือนเดิมทุกประการ WasmGC เป็นเพียงเครื่องมือใหม่ที่เป็นทางเลือกสำหรับภาษาที่สามารถได้รับประโยชน์จากมัน ทั้งสองโมเดลยังสามารถอยู่ร่วมกันได้ภายในแอปพลิเคชันเดียวกัน

ตัวอย่างเชิงแนวคิด: ก่อนและหลัง WasmGC

เพื่อให้เห็นความแตกต่างอย่างเป็นรูปธรรม ลองดูเวิร์กโฟลว์เชิงแนวคิดสำหรับการส่งผ่านอ็อบเจ็กต์ข้อมูลผู้ใช้จาก JavaScript ไปยัง Wasm

ก่อน WasmGC (เช่น Rust กับ wasm-bindgen)

ฝั่ง JavaScript:

            
const user = { id: 101, name: "Alice", isActive: true };
// 1. Serialize the object
const userJson = JSON.stringify(user);

// 2. Encode to UTF-8 and write to Wasm memory
const wasmMemoryBuffer = new Uint8Array(wasmModule.instance.exports.memory.buffer);
const pointer = wasmModule.instance.exports.allocate_memory(userJson.length + 1);
// ... code to write string to wasmMemoryBuffer at 'pointer' ...

// 3. Call Wasm function with pointer and length
const resultPointer = wasmModule.instance.exports.process_user(pointer, userJson.length);
// ... code to read result string from Wasm memory ...

            

              
                Copy
              
            
          

ซึ่งเกี่ยวข้องกับหลายขั้นตอน การแปลงข้อมูล และการจัดการหน่วยความจำอย่างระมัดระวังทั้งสองฝั่ง

หลัง WasmGC (เช่น Kotlin/Wasm)

ฝั่ง JavaScript:

            
const user = { id: 101, name: "Alice", isActive: true };

// 1. Simply call the exported Wasm function and pass the object
const result = wasmModule.instance.exports.process_user(user);

console.log(`Received processed name: ${result.name}`);

            

              
                Copy
              
            
          

ความแตกต่างนั้นชัดเจนมาก ความซับซ้อนของรอยต่อการทำงานร่วมกันได้หายไป นักพัฒนาสามารถทำงานกับอ็อบเจ็กต์ได้อย่างเป็นธรรมชาติทั้งใน JavaScript และภาษาที่คอมไพล์เป็น Wasm และเอนจิน Wasm จะจัดการการสื่อสารอย่างมีประสิทธิภาพและโปร่งใส

ความเชื่อมโยงกับ Component Model

WasmGC ยังเป็นก้าวสำคัญที่นำไปสู่วิสัยทัศน์ที่กว้างขึ้นสำหรับ WebAssembly นั่นคือ Component Model ซึ่งมีเป้าหมายเพื่อสร้างอนาคตที่ส่วนประกอบซอฟต์แวร์ที่เขียนด้วยภาษาใดๆ ก็ตามสามารถสื่อสารกันได้อย่างราบรื่นโดยใช้อินเทอร์เฟซระดับสูงที่สมบูรณ์ ไม่ใช่แค่ตัวเลขธรรมดาๆ เพื่อให้บรรลุเป้าหมายนี้ คุณต้องมีวิธีที่เป็นมาตรฐานในการอธิบายและส่งผ่านประเภทข้อมูลที่ซับซ้อน เช่น สตริง, ลิสต์ และเรคคอร์ด ระหว่างส่วนประกอบต่างๆ WasmGC เป็นเทคโนโลยีการจัดการหน่วยความจำพื้นฐานที่ทำให้การจัดการประเภทข้อมูลระดับสูงเหล่านี้มีประสิทธิภาพและเป็นไปได้

สรุป: อนาคตคือการจัดการที่มีประสิทธิภาพและรวดเร็ว

WebAssembly GC เป็นมากกว่าแค่ฟีเจอร์ทางเทคนิค มันคือการปลดล็อก มันทลายอุปสรรคสำคัญที่ขัดขวางระบบนิเวศขนาดใหญ่ของ managed languages และนักพัฒนาของพวกเขาจากการเข้าร่วมการปฏิวัติ WebAssembly อย่างเต็มรูปแบบ ด้วยการผสานรวมภาษาระดับสูงเข้ากับ garbage collector แบบเนทีฟที่ได้รับการปรับแต่งมาอย่างดีของเบราว์เซอร์ WasmGC ได้มอบคำมั่นสัญญาใหม่อันทรงพลัง: คุณไม่จำเป็นต้องเลือกระหว่างความสามารถในการผลิตระดับสูงกับประสิทธิภาพสูงบนเว็บอีกต่อไป

ผลกระทบจะลึกซึ้งอย่างยิ่ง เราจะได้เห็นคลื่นลูกใหม่ของเว็บแอปพลิเคชันที่ซับซ้อน ใช้ข้อมูลจำนวนมาก และมีประสิทธิภาพสูง ตั้งแต่เครื่องมือสร้างสรรค์และ data visualizations ไปจนถึงซอฟต์แวร์ระดับองค์กรเต็มรูปแบบ ซึ่งสร้างขึ้นด้วยภาษาและเฟรมเวิร์กที่ก่อนหน้านี้ไม่สามารถนำมาใช้กับเบราว์เซอร์ได้ มันทำให้ประสิทธิภาพบนเว็บเป็นประชาธิปไตย ทำให้นักพัฒนาทั่วโลกสามารถใช้ทักษะที่มีอยู่แล้วในภาษาอย่าง Java, C# และ Kotlin เพื่อสร้างประสบการณ์เว็บยุคถัดไป

ยุคของการต้องเลือกระหว่างความสะดวกสบายของ managed language กับประสิทธิภาพของ Wasm ได้สิ้นสุดลงแล้ว ด้วย WasmGC อนาคตของการพัฒนาเว็บจึงมีทั้งการจัดการที่มีประสิทธิภาพและรวดเร็วอย่างเหลือเชื่อ