V8 และ WebAssembly: โครงสร้างและการปรับแต่งประสิทธิภาพของเอนจิน JavaScript สมัยใหม่

บทความนี้เขียนโดยอ้างอิง V8 engine v11.x และจะพาไปดูให้ลึกกว่าการแนะนำ garbage collector แบบพื้นฐาน ว่า V8 จัดการการเรียกฟังก์ชันนับล้านครั้งต่อวินาทีและหน่วยความจำระดับ GB ได้อย่างมีประสิทธิภาพอย่างไร

หัวใจของการจัดการหน่วยความจำ: ทำความเข้าใจสถาปัตยกรรม V8

ที่ JavaScript สามารถพัฒนาจากภาษา scripting แบบเรียบง่ายไปเป็นแพลตฟอร์มสำหรับแอปพลิเคชันประสิทธิภาพสูงได้ ก็เป็นเพราะการจัดการหน่วยความจำอันล้ำสมัยของ V8 ในช่วงแรก V8 เคยทำให้ประสบการณ์ผู้ใช้แย่ลงจากการหยุดของ GC ที่กินเวลาหลายสิบมิลลิวินาที แต่ปัจจุบันลดลงมาเหลือเพียงระดับไม่กี่มิลลิวินาทีแล้ว จุดเริ่มต้นของการเปลี่ยนแปลงครั้งใหญ่ครั้งนี้เริ่มตั้งแต่วิธีที่ใช้แทนอ็อบเจ็กต์

วิธีแทนอ็อบเจ็กต์ที่ไม่เหมือนใคร: Hidden Classes

V8 แทน JavaScript object ภายในด้วย HeapObject และแต่ละอ็อบเจ็กต์จะมีโครงสร้างดังนี้

// โครงสร้างอ็อบเจ็กต์ภายในของ V8 (แบบย่อ)  
class HeapObject {  
  Map* map_;           // พอยน์เตอร์ไปยัง Hidden Class (4/8 bytes)  
  Properties* props_;  // ที่เก็บพร็อพเพอร์ตีแบบไดนามิก  
  Elements* elements_; // ที่เก็บองค์ประกอบของอาร์เรย์  
  // ... พร็อพเพอร์ตีแบบอินไลน์  
};  

Hidden Classes (Maps) คือเทคนิคการปรับแต่งประสิทธิภาพหลักของ V8 ที่ช่วยให้ภาษาชนิดไดนามิกสามารถทำประสิทธิภาพได้ในระดับใกล้เคียงกับภาษาชนิดสแตติก ทุกครั้งที่โครงสร้างอ็อบเจ็กต์เปลี่ยน ระบบจะเปลี่ยนผ่าน (transition) ไปยัง Hidden Class ใหม่ และเมื่อทำงานร่วมกับ Inline Cache(IC) ก็จะช่วยเพิ่มประสิทธิภาพการเข้าถึงพร็อพเพอร์ตี

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

ความท้าทายในโลกความจริง: ทำไมการจัดการหน่วยความจำจึงยาก

เว็บแอปพลิเคชันสมัยใหม่ใช้หน่วยความจำ heap จำนวนมาก และต้องรองรับแอนิเมชัน 60FPS รวมถึงการโต้ตอบแบบเรียลไทม์ GC ของ V8 จึงต้องแก้โจทย์ท้าทายต่อไปนี้

1. Latency vs Throughput trade-off: ลด GC pause time ให้ต่ำที่สุด ขณะเดียวกันก็ยังต้องได้อัตราการกู้คืนหน่วยความจำที่เพียงพอ
2. Memory Fragmentation: ป้องกันการกระจัดกระจายของหน่วยความจำใน SPA ที่ทำงานต่อเนื่องยาวนาน
3. Cross-heap References: จัดการการอ้างอิงข้ามกันระหว่าง JavaScript และ WebAssembly อย่างมีประสิทธิภาพ
4. Incremental/Concurrent processing: ทำ GC โดยไม่บล็อก main thread

โดยเฉพาะในสถาปัตยกรรม Site Isolation ของ Chrome แต่ละ iframe จะมี V8 isolate แยกกัน ทำให้ประสิทธิภาพด้านหน่วยความจำยิ่งมีความสำคัญมากขึ้น เพื่อรับมือกับความท้าทายเหล่านี้ V8 จึงนำแนวทางแบบนวัตกรรมที่เรียกว่าโครงสร้าง heap แบบแบ่งตามเจเนอเรชันมาใช้

กลยุทธ์หลัก: การออกแบบโครงสร้าง heap แบบแบ่งตามเจเนอเรชัน

โครงสร้าง heap แบบแบ่งตามเจเนอเรชันและกลยุทธ์การจัดสรรหน่วยความจำ

heap ของ V8 ไม่ได้แบ่งแค่ Young/Old แบบเรียบง่าย แต่มีโครงสร้างแบบลำดับชั้นที่ซับซ้อน

V8 Heap (ขนาดรวม: nn MB ~ n GB)  
├── Young Generation (1-32MB)  
│   ├── Nursery (Semi-space 1)  
│   ├── Intermediate (Semi-space 2)  
│   └── Survivor Space  
├── Old Generation  
│   ├── Old Object Space  
│   ├── Code Space (โค้ดที่รันได้)  
│   ├── Map Space (Hidden Classes)  
│   └── Large Object Space (>256KB อ็อบเจ็กต์)  
└── Non-movable Spaces  
    ├── Read-only Space  
    └── Shared Space (cross-isolate)  

โครงสร้างแบบลำดับชั้นนี้ทำให้สามารถจัดการได้อย่างเหมาะสมตามอายุของอ็อบเจ็กต์ ด้วยเทคนิค TLAB (Thread-Local Allocation Buffer) แต่ละเธรดจะมีบัฟเฟอร์สำหรับการจัดสรรของตัวเอง ซึ่งช่วยลด contention จากการทำงานพร้อมกัน การจัดสรรทำได้ในเวลา O(1) ด้วยวิธี bump pointer

แต่โครงสร้าง heap แบบแบ่งตามเจเนอเรชันนี้ตั้งอยู่บนสมมติฐานหนึ่ง

กลไกการเลื่อนระดับอ็อบเจ็กต์ตามเจเนอเรชัน (Promotion)

การเลื่อนระดับอ็อบเจ็กต์ของ V8 ไม่ได้อิงแค่ age แบบง่าย ๆ แต่ใช้ heuristic หลายด้านร่วมกัน

1. Age-based Promotion: อ็อบเจ็กต์ที่รอดจาก Scavenge มาได้ตั้งแต่ 2 ครั้งขึ้นไป
2. Size-based Promotion: หาก To-space ถูกใช้เกิน 25% จะเลื่อนระดับทันที
3. Pretenuring: ใช้ feedback จาก allocation site เพื่อจัดสรรลง Old Space ตั้งแต่แรก

// ตัวอย่าง Pretenuring - V8 เรียนรู้แพตเทิร์น  
function createLargeObject() {  
  return new Array(1000000); // หากถูกเรียกหลายครั้ง จะจัดสรรลง Old Space โดยตรง  
}  

Write Barrier ใช้ติดตามการอ้างอิงข้ามเจเนอเรชัน เมื่อเกิดการอ้างอิง Old -> Young จะมีการบันทึกลง remembered set เพื่อให้ถูกปฏิบัติเป็น root ระหว่าง Minor GC

// Write Barrier (แบบย่อ)  
if (is_old_object(obj) && is_young_object(value)) {  
  remembered_set.insert(obj_address);  
}  

[IMG] v8

การพิสูจน์สมมติฐานแบบแบ่งตามเจเนอเรชัน: Weak Generational Hypothesis

จากข้อมูลที่ทีม V8 วัดจริงพบว่า

• 95% ของอ็อบเจ็กต์หายไปตั้งแต่ Scavenge ครั้งแรก
• มีเพียง 2% เท่านั้นที่ถูกเลื่อนระดับไปยัง Old Generation
• GC ของ Young Generation ใช้เวลา 10-50ms ส่วน GC ของ Old Generation ใช้เวลา 100-1000ms

สถิติเหล่านี้อธิบายได้ว่าทำไม GC แบบแบ่งตามเจเนอเรชันจึงมีประสิทธิภาพ แต่ในเฟรมเวิร์ก SPA อย่าง React สมมติฐานนี้กลับพังลงอย่างสิ้นเชิง

การปะทะกันระหว่าง React กับ V8 GC: ปัญหาที่เกิดขึ้นจริง

1. รูปแบบหน่วยความจำของสถาปัตยกรรม Fiber

สถาปัตยกรรม Fiber ที่ถูกนำมาใช้ตั้งแต่ React 16 กำลังปะทะกับสมมติฐานแบบแบ่งตามเจเนอเรชันของ V8 โดยตรง

// โครงสร้างโหนด React Fiber (simplified)  
class FiberNode {  
  constructor(element) {  
    this.type = element.type;  
    this.key = element.key;  
    this.props = element.props;  
    
    // รีเฟอเรนซ์เหล่านี้คือหัวใจของปัญหา  
    this.child = null;      // Fiber ลูก  
    this.sibling = null;    // Fiber พี่น้อง  
    this.return = null;     // Fiber พ่อแม่  
    this.alternate = null;  // Fiber ของการเรนเดอร์ก่อนหน้า (double buffering)  
    
    // รีเฟอเรนซ์ที่มีอายุยืน  
    this.memoizedState = null;     // สถานะของ Hooks  
    this.memoizedProps = null;     // props ก่อนหน้า  
    this.updateQueue = null;        // คิวอัปเดต  
  }  
}  
  
// ต้นไม้ Fiber ในแอป React จริง  
const fiberRoot = {  
  current: rootFiber,        // ต้นไม้ปัจจุบัน (ถูกเลื่อนระดับไปยัง Old Generation)  
  workInProgress: null,      // ต้นไม้ที่กำลังทำงานอยู่ (Young Generation)  
  pendingTime: 0,  
  finishedWork: null  
};  

ปัญหา

• Fiber node จะคงอยู่ตลอดช่วงที่คอมโพเนนต์ยัง mount อยู่
• มีการสร้าง/คง alternate Fiber ไว้ทุกครั้งที่ render (double buffering)
• ต้นไม้ทั้งหมดถูกเลื่อนระดับไปยัง Old Generation ทำให้ภาระของ Major GC เพิ่มขึ้น

2. React Hooks และ memory leak ของ closure

// รูปแบบ memory leak ที่พบบ่อย  
function ExpensiveComponent() {  
  const [data, setData] = useState([]);  
  
  useEffect(() => {  
    // closure นี้จับ scope ทั้งหมดของคอมโพเนนต์ไว้  
    const timer = setInterval(() => {  
      setData(prev => [...prev, generateLargeObject()]);  
    }, 1000);  
    
    // ถ้าลืม cleanup function จะเกิด memory leak  
    return () => clearInterval(timer);  
  }, []); // แม้ deps จะว่างก็ยังมีการสร้าง closure  
  
  // สร้างฟังก์ชันใหม่ทุกครั้งที่ render (เพิ่มแรงกดดันต่อ Young Generation)  
  const handleClick = useCallback(() => {  
    // ฟังก์ชันนี้จับ data ทั้งหมดไว้ใน closure  
    console.log(data.length);  
  }, [data]);  
}  
  
// รูปแบบ Hook ที่ V8 ปรับแต่งได้ยาก  
function useComplexState() {  
  const [state, setState] = useState(() => {  
    // ฟังก์ชันเริ่มต้นนี้จะทำงานเพียงครั้งเดียว  
    // แต่ V8 คาดการณ์สิ่งนี้ได้ยาก  
    return createExpensiveInitialState();  
  });  
  
  // โครงสร้าง linked list ของ Hook สร้างภาระให้ GC  
  const hook = {  
    memoizedState: state,  
    queue: updateQueue,  
    next: nextHook  // อ้างอิงไปยัง Hook ถัดไป  
  };  
}  

3. memory overhead ของ Virtual DOM และ Reconciliation

// รูปแบบการสร้างอ็อบเจ็กต์ Virtual DOM  
function createElement(type, props, ...children) {  
  return {  
    $$typeof: REACT_ELEMENT_TYPE,  
    type,  
    key: props?.key || null,  
    ref: props?.ref || null,  
    props: { ...props, children },  
    _owner: currentOwner  // อ้างอิงไปยัง Fiber  
  };  
}  
  
// อ็อบเจ็กต์ชั่วคราวที่ถูกสร้างขึ้นทุกครั้งที่ render  
function render() {  
  // อ็อบเจ็กต์ทั้งหมดนี้ถูกสร้างใน Young Generation  
  return (  
    <div className="container">  
      {items.map(item => (  
        <Item   
          key={item.id}  
          data={item}  
          onClick={() => handleClick(item.id)}  
        />  
      ))}  
    </div>  
  );  
  // หลัง Reconciliation แล้ว ส่วนใหญ่จะถูกทิ้งทันที  
}  
  
// อ็อบเจ็กต์งานที่ถูกสร้างระหว่าง Reconciliation  
const updatePayload = {  
  type: 'UPDATE',  
  fiber: currentFiber,  
  partialState: newState,  
  callback: commitCallback,  
  next: null  // linked list ของ Update queue  
};  

4. React DevTools และการทำ memory profiling

// memory overhead ที่ React DevTools เพิ่มเข้ามา  
if (__DEV__) {  
  // เพิ่มข้อมูลดีบักให้แต่ละ Fiber  
  fiber._debugSource = element._source;  
  fiber._debugOwner = element._owner;  
  fiber._debugHookTypes = hookTypes;  
  
  // ข้อมูลเวลาเพื่อการ profiling  
  fiber.actualDuration = 0;  
  fiber.actualStartTime = 0;  
  fiber.selfBaseDuration = 0;  
  fiber.treeBaseDuration = 0;  
}  
  
// กลยุทธ์ปรับแต่ง memory profiling  
class MemoryOptimizedComponent extends React.Component {  
  shouldComponentUpdate(nextProps) {  
    // ลดการสร้าง Virtual DOM โดยป้องกันการ render ที่ไม่จำเป็น  
    return !shallowEqual(this.props, nextProps);  
  }  
  
  componentDidMount() {  
    // ใช้ WeakMap เพื่อการแคชที่เป็นมิตรกับ GC  
    this.cache = new WeakMap();  
  }  
  
  componentWillUnmount() {  
    // ล้างข้อมูลอย่างชัดเจนเพื่อป้องกัน memory leak  
    this.cache = null;  
    this.subscription?.unsubscribe();  
  }  
}  

5. Concurrent Features ของ React 18 และการปรับแต่ง GC

// Automatic Batching ของ React 18  
function handleMultipleUpdates() {  
  // เดิม: แต่ละ setState กระตุ้นการ render แยกกัน  
  // ปัจจุบัน: ถูกจัดเป็น batch อัตโนมัติ ช่วยลดภาระ GC  
  setCount(c => c + 1);  
  setFlag(f => !f);  
  setItems(i => [...i, newItem]);  
}  
  
// Suspense และการจัดการหน่วยความจำ  
const LazyComponent = React.lazy(() => {  
  // ลดการใช้หน่วยความจำเริ่มต้นด้วย dynamic import  
  return import('./HeavyComponent');  
});  
  
// การ render ตามลำดับความสำคัญด้วย useDeferredValue  
function SearchResults({ query }) {  
  const deferredQuery = useDeferredValue(query);  
  
  // อัปเดตที่ไม่เร่งด่วนจะถูกหน่วงไว้  
  // กระจายภาระของ Young Generation  
  return <ExpensiveList query={deferredQuery} />;  
}  

6. กรณีศึกษาการปรับแต่งในโปรดักชันจริง

// รูปแบบการปรับแต่งหน่วยความจำที่ Facebook ใช้  
const RecyclerListView = {  
  // ลดภาระ GC ด้วย object pooling  
  viewPool: [],  
  
  getView() {  
    return this.viewPool.pop() || this.createView();  
  },  
  
  releaseView(view) {  
    view.reset();  
    this.viewPool.push(view);  
  }  
};  
  
// กลยุทธ์แคชที่เป็นมิตรกับ GC ของ Relay  
class RelayCache {  
  constructor() {  
    // จัดการหน่วยความจำอัตโนมัติด้วย WeakMap  
    this.records = new WeakMap();  
    
    // การหมดอายุแบบ TTL เพื่อป้องกัน Old Generation เพิ่มขึ้น  
    this.ttl = 5 * 60 * 1000; // 5 นาที  
  }  
  
  gc() {  
    // ล้างเรคอร์ดเก่าเป็นระยะ  
    const now = Date.now();  
    for (const [key, record] of this.records) {  
      if (now - record.fetchTime > this.ttl) {  
        this.records.delete(key);  
      }  
    }  
  }  
}  

รูปแบบการใช้หน่วยความจำของ React เหล่านี้เคยขัดแย้งกับสมมติฐานพื้นฐานของทีม V8 แต่ด้วยความร่วมมืออย่างต่อเนื่องระหว่างทีม V8 และทีม React จึงเกิดการปรับแต่งได้อย่างมีประสิทธิภาพ โดยเฉพาะ Concurrent Features ของ React 18 ที่ถูกออกแบบมาให้ทำงานสอดประสานกับ Incremental GC ของ V8 ได้เป็นอย่างดี อ้างอิง

จากปัญหาสู่ทางแก้: วิวัฒนาการของอัลกอริทึม GC

โครงสร้างฮีปแบบแบ่งตามเจเนอเรชันเพียงอย่างเดียวยังไม่เพียงพอ แล้วจะทำอย่างไรจึงจะไม่ต้องหยุดแอปพลิเคชันระหว่างเก็บกวาดขยะ? ประวัติของ V8 คือกระบวนการค้นหาคำตอบของปัญหานี้

จุดเริ่มต้น: ข้อจำกัดของอัลกอริทึมแบบเรียบง่าย

V8 ยุคแรกในปี 2008 ใช้ตัวเก็บกวาดแบบ Semi-space ที่อิงกับ Cheney's Algorithm ซึ่งเป็น Copy Algorithm ที่เป็นตัวแทนสำคัญ

// Cheney Algorithm 의 Pseudocode  
void scavenge() {  
  scan = next = to_space.bottom;  
  // 1. 루트 스캐닝  
  for (root in roots) {  
    *root = copy(*root);  
  }  
  // 2. 너비 우선 탐색  
  while (scan < next) {  
    for (slot in slots_in(scan)) {  
      *slot = copy(*slot);  
    }  
    scan += object_size(scan);  
  }  
}  

อัลกอริทึมนี้เรียบง่ายและมีประสิทธิภาพ แต่มีปัญหาร้ายแรงสำหรับเว็บแอปพลิเคชันสมัยใหม่

• สูญเสียหน่วยความจำ 50%: ข้อจำกัดโดยธรรมชาติของ Semi-space
• Cache Locality แย่ลง: L1/L2 cache miss จากการท่องแบบ BFS
• คอขวดแบบเธรดเดียว: งานทั้งหมดทำได้เฉพาะบนเมนเธรด

จุดเริ่มต้นของนวัตกรรม: เปลี่ยนผ่านสู่ Tri-color Marking

V8 นำอัลกอริทึม Tri-color Marking มาใช้เพื่อทำ incremental marking

// Tri-color invariant  
enum MarkColor {  
  WHITE = 0,  // 미방문, 회수 대상  
  GREY = 1,   // 방문했으나 자식 미처리  
  BLACK = 2   // 방문 완료, 살아있음  
};  
  
// 증분 마킹을 위한 Barrier   
void WriteBarrier(HeapObject* obj, Object** slot, Object* value) {  
  if (marking_state == INCREMENTAL &&  
      IsBlack(obj) && IsWhite(value)) {  
    // tri-color 위반  
    MarkGrey(value);  // 불변성 유지  
    marking_worklist.Push(value);  
  }  
}  

แนวทางนี้ทำให้สามารถทำมาร์กกิงแบบค่อยเป็นค่อยไประหว่างที่ JavaScript กำลังรันอยู่ได้ แต่ก็ยังคงมีปัญหาพื้นฐานอยู่ว่าเมนเธรดยังต้องทำงาน GC เอง เพื่อแก้ปัญหานี้ ทีม V8 จึงตัดสินใจลองแนวทางที่กล้ากว่าเดิม

การเปลี่ยนกระบวนทัศน์: ความท้าทายของโปรเจกต์ Orinoco

Incremental GC เพียงอย่างเดียวยังไม่พอ โปรเจกต์ Orinoco คือการยกเครื่อง GC ครั้งใหญ่ของ V8 ที่เริ่มตั้งแต่ปี 2015 โดยตั้งเป้าอย่าง大胆ว่า "Free the main thread(ปลดปล่อยเมนเธรด)" เพื่อทำให้สิ่งนี้เกิดขึ้น จึงมีการนำเสนอเทคโนโลยีนวัตกรรม 3 อย่าง

1. การประมวลผลแบบขนาน (Parallel GC)

GC แบบขนานทำให้หลายเธรดทำงาน GC พร้อมกันได้ V8 ใช้อัลกอริทึม Work-Stealing เพื่อให้เกิดการกระจายโหลดอย่างสมดุล

class ParallelMarker {  
  std::atomic<Object*> marking_worklist;  
  std::atomic<size_t> bytes_marked;  
  
  void MarkInParallel() {  
    while (Object* obj = marking_worklist.pop()) {  
      MarkObject(obj);  
      // 로컬 작업 큐가 비어있을 때  
      if (local_worklist.empty()) {  
        StealFromOtherThread();  
      }  
    }  
  }  
};  

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

2. การประมวลผลแบบเพิ่มทีละขั้น (Incremental Marking)

Incremental marking จะแบ่งงาน GC ออกเป็นหลายช่วง โดยแต่ละช่วงใช้เวลาเพียง 5-10ms

// 증분 단계 트리거링  
function shouldTriggerIncrementalStep() {  
  const allocated = bytesAllocatedSinceLastStep();  
  const threshold = heap.size() * 0.01; // 1% of heap  
  return allocated > threshold;  
}  
  
// 증분 단계마다 ~1MB를 처리  
function incrementalMarkingStep() {  
  const deadline = performance.now() + 5; // 5ms budget  
  while (performance.now() < deadline && !marking_worklist.empty()) {  
    markNextObject();  
  }  
}  

Marking Progress Bar: ภายใน V8 จะติดตามความคืบหน้าของการมาร์กเพื่อปรับสมดุลระหว่างความเร็วในการจัดสรรกับความเร็วในการมาร์ก นี่เป็นความก้าวหน้าที่สำคัญ แต่ทางออกเชิงรากฐานจริง ๆ อยู่ที่การประมวลผลพร้อมกัน

3. การประมวลผลพร้อมกัน (Concurrent Marking)

Concurrent marking เป็นเทคนิคที่ซับซ้อนที่สุด แต่ก็มีประสิทธิภาพมากที่สุด V8 ใช้เทคนิค Snapshot-at-the-Beginning (SATB)

class ConcurrentMarker {  
  void WriteBarrierSATB(HeapObject* obj, Object** slot, Object* new_value) {  
    Object* old_value = *slot;  
    if (concurrent_marking_active &&   
        IsWhite(old_value) && !IsWhite(new_value)) {  
      // SATB를 위해 이전 참조 보존  
      satb_buffer.push(old_value);  
    }  
    *slot = new_value;  
  }  
  
  void ConcurrentMarkingTask() {  
    // 헬퍼 스레드에서 실행  
    while (!marking_worklist.empty()) {  
      Object* obj = marking_worklist.pop();  
      // CAS를 사용한 lock-free 마킹  
      if (TryMarkBlack(obj)) {  
        VisitPointers(obj);  
      }  
    }  
  }  
};  

ผลกระทบด้านประสิทธิภาพ: concurrent marking ลดเวลา pause ของ Major GC ลงได้ 60-70%

V8 ในปัจจุบัน: การผสานกันของเทคโนโลยีทั้งสาม

เทคโนโลยีทั้งสามที่พัฒนาผ่านโปรเจกต์ Orinoco ตอนนี้ได้กลายเป็นแกนหลักของ GC ใน V8 แล้ว มาดูกันว่าแต่ละเทคนิคทำงานประสานกันอย่างไรในแต่ละเฟสของ GC

Young Generation: การทำ Scavenging แบบขนาน

GC ของ Young Generation ถูก ทำให้ขนานอย่างสมบูรณ์ เมนเธรดยังคงต้องหยุด แต่มีหลาย helper thread ทำงานพร้อมกัน

class ParallelScavenger {  
  void Scavenge() {  
    // 1. 루트 스캔을 병렬로 수행  
    parallel_for(roots, [](Root* root) {  
      EvacuateObject(root->object);  
    });  
    
    // 2. Work stealing으로 부하 균형  
    while (has_work() || can_steal_work()) {  
      Object* obj = get_next_object();  
      CopyToSurvivor(obj);  
    }  
    
    // 3. 포인터 업데이트도 병렬로  
    parallel_update_pointers();  
  }  
};  

ผลลัพธ์: บนระบบ 8 คอร์ เวลา Young GC ลดจาก 50ms -> 7ms

Old Generation: ใช้ความเป็น concurrent ให้มากที่สุด

GC ของ Old Generation ใช้ความเป็น concurrent อย่างเต็มที่

1. เริ่มทำ Marking แบบทำงานพร้อมกัน: เริ่มในเบื้องหลังระหว่างที่ JavaScript กำลังรัน
2. Incremental Marking: เธรดหลักช่วยเป็นระยะครั้งละ 5ms
3. เก็บงานขั้นสุดท้าย: ทำ Marking ให้เสร็จด้วย pause สั้น ๆ (2-3ms)
4. Concurrent Sweeping: กลับไปคืนหน่วยความจำในเบื้องหลังอีกครั้ง

// ตัวอย่างไทม์ไลน์  
[JS 실행]-->[동시 마킹 시작]-->[JS 계속]-->[증분 5ms]-->[JS 계속]-->[최종 2ms]-->[JS 재개]  
    ↑            ↑             ↑           ↑  
할당 임계값 도달   백그라운드 작업   협력적 처리   최소 중단  

Idle-time GC: การจัดตารางแบบ Idle Time

การใช้ประโยชน์จาก Idle Time ของเบราว์เซอร์เป็นกลยุทธ์สำคัญของ V8

// ทำงานร่วมกับ requestIdleCallback ของ Chrome  
requestIdleCallback((deadline) => {  
  // ตรวจสอบเวลาที่เหลือ  
  const timeRemaining = deadline.timeRemaining();  
  
  if (timeRemaining > 10) {  
    // ถ้ามีเวลาเพียงพอ ให้ทำ Major GC  
    triggerMajorGC();  
  } else if (timeRemaining > 2) {  
    // ถ้ามีเวลาสั้น ๆ ให้ทำ Minor GC  
    triggerMinorGC();  
  }  
});  

การทำงานร่วมกันอย่างกลมกลืนของเทคนิคทั้งสามนี้ทำให้สามารถทำ GC ได้ในระดับที่ผู้ใช้แทบไม่รู้สึกถึงมันเลย ทั้งยังรันแอนิเมชัน 60FPS ได้อย่างลื่นไหลโดยไม่สะดุด พร้อมกับจัดการหน่วยความจำได้อย่างมีประสิทธิภาพ

เจาะลึก: รายละเอียดการติดตั้งใช้งานของอัลกอริทึมหลัก

ตอนนี้มาดูกันอย่างละเอียดว่าอัลกอริทึมหลักของ V8 GC ถูกนำไปติดตั้งใช้งานจริงอย่างไร

กลไกอันประณีตของ Concurrent Marking

หัวใจสำคัญของการทำ Marking แบบทำงานพร้อมกันคือการรักษา Tri-color Invariant

class ConcurrentMarkingVisitor {  
  void VisitPointers(HeapObject* host, ObjectSlot start, ObjectSlot end) {  
    for (ObjectSlot slot = start; slot < end; ++slot) {  
      Object* target = *slot;  
      
      // 1. 이미 방문한 객체는 건너뜀  
      if (IsBlackOrGrey(target)) continue;  
      
      // 2. 동시성 안전을 위한 CAS 연산  
      if (CompareAndSwapColor(target, WHITE, GREY)) {  
        // 3. 작업 큐에 추가 (lock-free queue)  
        marking_worklist_.Push(target);  
        
        // 4. Write barrier 활성화  
        if (host->IsInOldSpace()) {  
          remembered_set_.Insert(slot);  
        }  
      }  
    }  
  }  
};  

กลยุทธ์การกระจายงานของ Parallel Scavenger

Parallel Scavenger ใช้ Dynamic Work Stealing

class WorkStealingQueue {  
  bool TrySteal(Object** obj) {  
    // 1. 먼저 로컬 큐 확인  
    if (local_queue_.Pop(obj)) return true;  
    
    // 2. 로컬이 비어있으면 다른 스레드에서 Steal  
    for (int i = 0; i < num_threads; i++) {  
      if (global_queues_[i].TryStealHalf(&local_queue_)) {  
        return local_queue_.Pop(obj);  
      }  
    }  
    
    // 3. 모든 큐가 비어있으면 종료  
    return false;  
  }  
};  

ด้วยการติดตั้งใช้งานอัลกอริทึมเหล่านี้อย่างประณีต V8 จึงสามารถดึงประสิทธิภาพของระบบมัลติคอร์ออกมาใช้ได้อย่างเต็มที่

อีกแกนหนึ่งของวิวัฒนาการด้านประสิทธิภาพ: ความก้าวหน้าของคอมไพเลอร์

GC เพียงอย่างเดียวยังไม่พอ การปฏิวัติด้านประสิทธิภาพของ V8 เกิดจากการพัฒนาคอมไพเลอร์และ GC อย่างสมดุล

วิวัฒนาการของ compiler pipeline ใน V8

รุ่นที่ 1: Full-codegen + Crankshaft (2010-2016)

V8 ในช่วงแรกใช้กลยุทธ์การคอมไพล์แบบสองขั้นตอน

// ตัวอย่าง: ฟังก์ชันเป้าหมายสำหรับการปรับแต่งประสิทธิภาพ  
function calculateSum(arr) {  
  let sum = 0;  
  for (let i = 0; i < arr.length; i++) {  
    sum += arr[i];  // Hot Loop - Crankshaft ทำ optimization  
  }  
  return sum;  
}  
  
// Full-codegen: คอมไพล์เร็ว, รันช้า  
// -> แปลงโค้ดทั้งหมดเป็น native code ทันที  
  
// Crankshaft: คอมไพล์ช้า, รันเร็ว  
// -> ทำ optimization แบบเลือกเฉพาะกับฟังก์ชันที่ hot  

ปัญหา

• ใช้หน่วยความจำมากเกินไป (ทุกฟังก์ชันเป็น native code)
• เกิดการยกเลิกการปรับแต่งประสิทธิภาพ (Deoptimization) บ่อยครั้ง
• รับมือกับแพตเทิร์น JavaScript ที่ซับซ้อนได้ยาก

รุ่นที่ 2: Ignition + TurboFan (2016-ปัจจุบัน)

ในปี 2016 ทีม V8 ได้นำ pipeline แบบใหม่ทั้งหมดมาใช้เพื่อปรับปรุงทั้งประสิทธิภาพและการใช้หน่วยความจำ Ignition คืออินเทอร์พรีเตอร์ที่แปลง JavaScript เป็น bytecode ขนาดกะทัดรัด ซึ่งลดการใช้หน่วยความจำลงได้ 50-75% เมื่อเทียบกับ Full-codegen ส่วน TurboFan คือ optimizing compiler ที่มาแทน Crankshaft และทำ optimization ที่ซับซ้อนยิ่งกว่าเดิม

// วิธีการทำงานของ bytecode interpreter ของ Ignition  
function Component({ data }) {  
  // 1. parsing -> สร้าง AST  
  // 2. Ignition แปลงเป็น bytecode  
  const result = data.map(item => item * 2);  
  
  // 3. ติดตามจำนวนครั้งที่รัน (Feedback Vector)  
  // 4. ฟังก์ชันที่ hot จะถูกส่งต่อให้ TurboFan  
  return result;  
}  
  
// ตัวอย่าง bytecode จริง (ย่อให้ง่าย)  
/*  
  LdaNamedProperty a0, [0]    // โหลด data  
  CallProperty1 [1], a0, a1   // เรียก map  
  Return                      // คืนค่าผลลัพธ์  
*/  

การปรับปรุงสำคัญ:

• ประสิทธิภาพด้านหน่วยความจำ: bytecode มีขนาดเล็กกว่า native code มาก จึงเหมาะกับสภาพแวดล้อมบนมือถือ
• เริ่มต้นได้เร็ว: การสร้าง bytecode เร็วมาก ช่วยลดเวลาโหลดช่วงแรก
• การทำ optimization แบบค่อยเป็นค่อยไป: ทำ optimization ด้วย TurboFan เฉพาะส่วนที่จำเป็นเพื่อประหยัดทรัพยากร

Inline Caching (IC) และ Hidden Classes

Inline Caching คือเทคนิคที่ช่วยลดต้นทุนของการเข้าถึงพร็อพเพอร์ตี ซึ่งเป็นจุดอ่อนใหญ่ที่สุดของภาษาที่มีชนิดข้อมูลแบบไดนามิกได้อย่างมหาศาล ใน JavaScript ทุกครั้งที่รัน obj.property จะต้องมีขั้นตอนตรวจสอบชนิดของออบเจ็กต์และค้นหาพร็อพเพอร์ตี แต่ IC จะ cache ข้อมูลชนิดที่เคยเห็นมาก่อนแล้วนำกลับมาใช้ซ้ำ

Hidden Classes (หรือ Maps) คือเมทาดาทาภายในที่กำหนดโครงสร้างของออบเจ็กต์ ออบเจ็กต์ที่มีพร็อพเพอร์ตีเหมือนกันในลำดับเดียวกันจะใช้ Hidden Class เดียวกันร่วมกัน และด้วยสิ่งนี้ V8 จึงสามารถทำประสิทธิภาพการเข้าถึงพร็อพเพอร์ตีได้ในระดับเดียวกับ C++

// ตัวอย่างการเปลี่ยน Hidden Class  
class Point {  
  constructor(x, y) {  
    this.x = x;  // Hidden Class C0 -> C1  
    this.y = y;  // Hidden Class C1 -> C2  
  }  
}  
  
// Monomorphic (แบบรูปเดียว): ปรับแต่งได้  
function getX(point) {  
  return point.x;  // Hidden Class เดิมเสมอ  
}  
  
// Polymorphic (หลายรูปแบบ): ปรับแต่งได้ยาก  
function getValue(obj) {  
  return obj.value;  // อาจมี Hidden Class ได้หลากหลาย  
}  
  
// ตัวอย่างใน React component  
function UserProfile({ user }) {  
  // หากโครงสร้าง props คงที่ IC จะทำงานได้มีประสิทธิภาพ  
  return <div>{user.name}</div>;  
}  
  
// Anti-pattern: เพิ่มพร็อพเพอร์ตี้แบบไดนามิก  
function BadComponent({ data }) {  
  if (someCondition) {  
    data.extraField = 'value';  // Hidden Class เปลี่ยน!  
  }  
  return <div>{data.value}</div>;  
}  

วงจรป้อนกลับของการปรับแต่ง

Adaptive Optimization ของ V8 จะค่อย ๆ ปรับแต่งโค้ดโดยอิงจากข้อมูลรันไทม์ที่เก็บระหว่างการทำงาน กระบวนการนี้แบ่งได้เป็นสามขั้นตอน

1. Cold: ฟังก์ชันที่เพิ่งถูกรันครั้งแรกจะถูกตีความโดย Ignition
2. Warm: เมื่อถูกเรียกหลายครั้ง ระบบจะเก็บ type feedback และรูปแบบการทำงาน
3. Hot: เมื่อเกินค่า threshold (โดยทั่วไป 1000-10000 ครั้ง) TurboFan จะเข้ามาปรับแต่ง

วงจรป้อนกลับนี้ทำให้สามารถปรับแต่งให้ตรงกับรูปแบบการใช้งานจริง และช่วยป้องกันการสิ้นเปลืองทรัพยากรจากการปรับแต่งที่ไม่จำเป็น

// กระบวนการตัดสินใจปรับแต่งของ V8  
class OptimizationExample {  
  // ฟังก์ชัน Cold: ทำงานบน Ignition เท่านั้น  
  rarely_called() {  
    return Math.random();  
  }  
  
  // ฟังก์ชัน Warm: เก็บ type feedback  
  sometimes_called(x, y) {  
    return x + y;  // บันทึกข้อมูลประเภท  
  }  
  
  // ฟังก์ชัน Hot: ปรับแต่งด้วย TurboFan  
  frequently_called(arr) {  
    // จำนวนครั้งที่รัน > threshold => ทริกเกอร์การปรับแต่ง  
    let sum = 0;  
    for (let i = 0; i < arr.length; i++) {  
      sum += arr[i];  
    }  
    return sum;  
  }  
}  
  
// ตัวอย่างการเก็บ type feedback  
let feedback = {  
  callCount: 0,  
  parameterTypes: [],  
  returnTypes: []  
};  
  
// ในกรณีของ React: ฟังก์ชัน render ถูกเรียกบ่อย จึงมักเป็นเป้าหมายของการปรับแต่ง  
function FrequentlyRendered({ items }) {  
  // มีโอกาสสูงที่ TurboFan จะปรับแต่ง  
  return items.map((item, i) => (  
    <Item key={i} data={item} />  
  ));  
}  

เทคนิคการปรับแต่งขั้นสูงของ TurboFan

TurboFan ไม่ใช่แค่ JIT compiler แบบเรียบง่าย แต่เป็น optimizing compiler ที่ซับซ้อนอย่างมาก โดยใช้ตัวแทนกลาง (IR) ที่เรียกว่า Sea of Nodes เพื่อทำการปรับแต่งหลากหลายรูปแบบ

// 1. Inlining  
// ลดโอเวอร์เฮดจากการเรียกฟังก์ชันขนาดเล็ก ช่วยเพิ่มประสิทธิภาพ 10-30%  
function add(a, b) { return a + b; }  
function calculate(x, y) {  
  return add(x, y) * 2;  
  // หลังปรับแต่ง: return (x + y) * 2;  
  // ตัดต้นทุนการเรียกฟังก์ชัน + เปิดโอกาสให้ปรับแต่งเพิ่มเติม  
}  
  
// 2. Escape Analysis  
// หลีกเลี่ยงการจัดสรรหน่วยความจำบน heap สำหรับอ็อบเจ็กต์ชั่วคราว เพื่อลดภาระ GC  
function createPoint() {  
  const point = { x: 10, y: 20 };  // เดิมทีถูกจัดสรรบน heap  
  return point.x + point.y;  // อ็อบเจ็กต์ไม่หลุดออกนอกฟังก์ชัน  
  // หลังปรับแต่ง: return 30;  // คำนวณได้ตั้งแต่ช่วงคอมไพล์  
  // ผลลัพธ์: ต้นทุนการสร้างอ็อบเจ็กต์เป็น 0 และไม่ตกเป็นเป้าของ GC  
}  
  
// 3. การปรับแต่งลูป  
function processArray(arr) {  
  // Loop unrolling: ลดจำนวนรอบเพื่อให้ branch prediction ผิดพลาดน้อยลง  
  for (let i = 0; i < arr.length; i += 4) {  
    // เดิมต้องเช็กเงื่อนไขทุกครั้งที่วน  
    // หลังปรับแต่ง: ประมวลผลทีละ 4 ค่า  
    arr[i] = arr[i] * 2;  
    arr[i+1] = arr[i+1] * 2;  
    arr[i+2] = arr[i+2] * 2;  
    arr[i+3] = arr[i+3] * 2;  
  }  
  // ประสิทธิภาพ: ดีขึ้นได้สูงสุด 4 เท่า (ประสิทธิภาพของ CPU pipeline)  
}  
  
// 4. การปรับแต่งที่ใช้ใน React  
const MemoizedComponent = React.memo(({ data }) => {  
  // TurboFan ปรับแต่งตรรกะการเปรียบเทียบ props  
  return <ExpensiveRender data={data} />;  
});  

การวัดประสิทธิภาพจริงและการทำโปรไฟล์

สามารถตรวจสอบผลของการปรับแต่งจากคอมไพเลอร์ได้ด้วยการวัดจริง โดยใช้แท็บ Performance ของ Chrome DevTools หรือใช้แฟลก --trace-opt ของ Node.js เพื่อสังเกตกระบวนการปรับแต่งโดยตรง

// ตรวจสอบการทำงานของคอมไพเลอร์ใน Chrome DevTools  
function profileFunction() {  
  // 1. การรันช่วงแรก: Ignition interpreter  
  console.time('cold');  
  calculateSum([1,2,3,4,5]);  
  console.timeEnd('cold');  
  
  // 2. การรันซ้ำ: เก็บ type feedback  
  for (let i = 0; i < 1000; i++) {  
    calculateSum([1,2,3,4,5]);  
  }  
  
  // 3. การรันแบบ Hot: โค้ดที่ TurboFan ปรับแต่งแล้ว  
  console.time('hot');  
  calculateSum([1,2,3,4,5]);  
  console.timeEnd('hot');  // เร็วขึ้นมาก  
}  
  
// ตรวจสอบสถานะการปรับแต่งด้วยแฟลกของ V8  
// node --trace-opt --trace-deopt script.js  

การทำงานส่งเสริมกันของ React และการปรับแต่งคอมไพเลอร์ของ V8

React ถูกออกแบบโดยคำนึงถึงคุณลักษณะการปรับแต่งของ V8 โดยเฉพาะ Concurrent Features ของ React 18 ที่ทำงานสอดรับกับรูปแบบการปรับแต่งของ V8 ได้เป็นอย่างดี

// แพตเทิร์นที่เป็นมิตรกับคอมไพเลอร์ใน React 18  
function OptimizedComponent() {  
  // 1. ใช้ชนิดข้อมูลอย่างสม่ำเสมอ  
  const [count, setCount] = useState(0);  // เป็น number เสมอ  
  
  // 2. การปรับแต่ง conditional rendering  
  const content = useMemo(() => {  
    // โครงสร้างที่ TurboFan ปรับแต่งได้ง่าย  
    return count > 10 ? <Heavy /> : <Light />;  
  }, [count]);  
  
  // 3. การปรับแต่ง event handler  
  const handleClick = useCallback((e) => {  
    // คงการอ้างอิงฟังก์ชันเดิมไว้ => IC มีประสิทธิภาพ  
    setCount(c => c + 1);  
  }, []);  
  
  return <div onClick={handleClick}>{content}</div>;  
}  
  
// การทำงานร่วมกันของ React Compiler (รุ่นทดลอง) และ V8  
// React Compiler ทำการปรับแต่งตั้งแต่ช่วงคอมไพล์  
// เพื่อสร้างโค้ดที่ V8 สามารถรันได้อย่างมีประสิทธิภาพมากขึ้นในรันไทม์  

แอนตี้แพตเทิร์นด้านการเพิ่มประสิทธิภาพและแนวทางแก้ไข

มีแอนตี้แพตเทิร์นทั่วไปหลายอย่างที่ขัดขวางการเพิ่มประสิทธิภาพของ V8 หากหลีกเลี่ยงสิ่งเหล่านี้ได้ ก็อาจได้ประสิทธิภาพเพิ่มขึ้น 2-10 เท่า

// แอนตี้แพตเทิร์น 1: Hidden Class ปนเปื้อน  
function bad() {  
  const obj = {};  
  obj.a = 1;      // HC1  
  obj.b = 2;      // HC2  
  delete obj.a;   // HC3 - ยกเลิกการเพิ่มประสิทธิภาพ  
}  
  
// แนวทางแก้: ตรึงโครงสร้าง  
function good() {  
  const obj = { a: 1, b: 2 };  // สร้างครั้งเดียวให้ครบ  
  if (needToRemove) {  
    obj.a = undefined;  // ใช้ undefined แทน delete  
  }  
}  
  
// แอนตี้แพตเทิร์น 2: ความเป็นพหุสัณฐานมากเกินไป  
function processItems(items) {  
  items.forEach(item => {  
    // item มีหลายประเภท => เพิ่มประสิทธิภาพได้ยาก  
    console.log(item.value);  
  });  
}  
  
// แนวทางแก้: ทำให้ประเภทข้อมูลเป็นแบบเดียวกัน  
interface Item {  
  value: number;  
  type: string;  
}  
function processTypedItems(items: Item[]) {  
  // ประเภทข้อมูลสม่ำเสมอ => IC ทำงานได้มีประสิทธิภาพ  
  items.forEach(item => console.log(item.value));  
}  

ความก้าวหน้าของคอมไพเลอร์ได้ปฏิวัติความเร็วในการรันของ JavaScript อย่างสิ้นเชิง โดยเฉพาะเฟรมเวิร์กอย่าง React ที่ถูกออกแบบโดยคำนึงถึงคุณลักษณะการเพิ่มประสิทธิภาพของ V8 จึงพัฒนาไปในทิศทางที่ช่วยให้นักพัฒนาสามารถได้ประสิทธิภาพที่ดีแม้ไม่ได้ตั้งใจปรับแต่งเอง แต่ไม่ว่าคอมไพเลอร์จะเร็วแค่ไหน ทุกอย่างก็อาจพังลงได้จากการจัดการหน่วยความจำที่ไม่มีประสิทธิภาพ ตอนนี้มาดูนวัตกรรมในอีกแกนหนึ่งกัน

กลยุทธ์เสริม: เทคนิคการเพิ่มประสิทธิภาพหน่วยความจำที่หลากหลาย

นอกจากกลยุทธ์พื้นฐานของ GC แล้ว V8 ยังใช้เทคนิคเสริมอีกหลายแบบ สิ่งเหล่านี้ช่วยลดภาระของ GC ได้อย่างมากในบางสถานการณ์

1. Object Pooling

Object Pooling คือแพตเทิร์นที่สร้างอ็อบเจ็กต์ที่ถูกสร้าง/ทำลายบ่อยไว้ล่วงหน้าแล้วนำกลับมาใช้ซ้ำ เทคนิคนี้ให้ผลดีมากเป็นพิเศษในสภาพแวดล้อมอย่างเกมหรือแอนิเมชันที่มีการสร้างอ็อบเจ็กต์จำนวนมากในทุกเฟรม

หลักการทำงาน: แทนที่จะสร้างและทำลายอ็อบเจ็กต์ตั้งแต่ต้นจนจบ เมื่อใช้งานเสร็จแล้วก็คืนอ็อบเจ็กต์กลับเข้า pool และนำมาใช้ซ้ำเมื่อจำเป็น วิธีนี้ช่วยลดแรงกดดันต่อ Young Generation และลดความถี่ของ GC ได้อย่างชัดเจน

// การทำ Object Pool แบบง่าย (simplified)  
class ObjectPool {  
  constructor(createFn, maxSize = 100) {  
    this.createFn = createFn;  
    this.pool = Array(maxSize).fill(null).map(createFn);  
  }  
  
  acquire() {  
    return this.pool.pop() || this.createFn();  
  }  
  
  release(obj) {  
    this.pool.push(obj);  
  }  
}  
  
// ตัวอย่างการใช้งานใน React  
const bulletPool = new ObjectPool(  
  () => ({ x: 0, y: 0, active: false }),   
  1000  // pool กระสุน 1,000 นัด  
);  

การเปรียบเทียบประสิทธิภาพ:

จากผลการวัดจริง ระบบอนุภาคที่ใช้ Object Pooling มี GC pause ลดลง 70% เมื่อเทียบกับเวอร์ชันที่ไม่ใช้ pooling และอาการเฟรมดรอปก็แทบหายไป โดยเฉพาะบนอุปกรณ์พกพาที่เห็นผลชัดเจนยิ่งกว่า

// การเปรียบเทียบประสิทธิภาพ  
const particles = [];  
for (let i = 0; i < 10000; i++) {  
  // Without pooling: สร้างอ็อบเจ็กต์ใหม่ทุกครั้ง  
  particles.push({ x: Math.random() * 800, y: 600 });  
  
  // With pooling: ใช้อ็อบเจ็กต์ซ้ำ  
  // const p = pool.acquire();  
  // p.x = Math.random() * 800;  
}  
// ผลลัพธ์: GC pause ลดลง 70%, แก้ปัญหาเฟรมดรอป  

2. Memory Compaction

การกระจัดกระจายของหน่วยความจำเป็นปัญหาเรื้อรังของแอปพลิเคชันที่ทำงานเป็นเวลานาน V8 จึงทำการบีบอัดหน่วยความจำเป็นระยะเพื่อแก้ปัญหานี้

ปัญหาการกระจัดกระจาย: เมื่อมีการสร้าง/ทำลายอ็อบเจ็กต์ที่มีขนาดต่างกันซ้ำๆ จะเกิดช่องว่างขนาดเล็กที่ใช้งานไม่ได้ในหน่วยความจำ ส่งผลให้เกิดสถานการณ์ที่แม้จะมีหน่วยความจำว่างเพียงพอ ก็ยังไม่สามารถจัดสรรอ็อบเจ็กต์ขนาดใหญ่ได้

กลยุทธ์การบีบอัดของ V8: ในช่วง Major GC จะย้ายอ็อบเจ็กต์ที่ยังมีชีวิตอยู่ไปยังพื้นที่หน่วยความจำที่ต่อเนื่องกันเพื่อรวมช่องว่างให้เป็นก้อนเดียว กระบวนการนี้มีต้นทุนสูง แต่จะอาศัย Idle time เพื่อให้ผู้ใช้ไม่รู้สึกถึงผลกระทบ

// ตัวอย่างการกระจัดกระจายของหน่วยความจำ  
class FragmentationExample {  
  constructor() {  
    // แพตเทิร์นที่ก่อให้เกิดการกระจัดกระจาย  
    this.data = [];  
    
    // ตัวอย่างการกระจัดกระจาย: มีทั้งอ็อบเจ็กต์ใหญ่และเล็กปะปนกันแล้วลบบางส่วนออก  
    // ผลลัพธ์: พื้นที่ว่างในหน่วยความจำกระจายตัวไม่สม่ำเสมอ  
  }  
}  
  
// กลยุทธ์การเพิ่มประสิทธิภาพสำหรับนักพัฒนา  
const optimized = {  
  smallObjects: [],     // จัดกลุ่มตามขนาด  
  largeObjects: [],     // ป้องกันการกระจัดกระจาย  
  buffer: new ArrayBuffer(1024 * 1024), // หน่วยความจำต่อเนื่อง  
};  

3. Pointer Compression

Chrome 80 เป็นเวอร์ชันที่เริ่มนำ Pointer Compression มาใช้ ซึ่งช่วยลดการใช้หน่วยความจำของ V8 ได้อย่างมาก บนระบบ 64 บิต การที่พอยน์เตอร์ทุกตัวกินพื้นที่ 8 ไบต์ถือเป็นโอเวอร์เฮดที่มากเกินไปสำหรับภาษาระดับสูงอย่าง JavaScript

กลไกการบีบอัด: V8 จะจัดสรร JavaScript object เฉพาะภายในพื้นที่ “cage” ขนาด 4GB และแทนที่อยู่ภายในพื้นที่นี้ด้วย offset แบบ 32 บิต จากนั้นจึงกู้คืนที่อยู่ 64 บิตจริงด้วยวิธี Base address + 32bit offset

ผลลัพธ์จริง: จากการวัดใน Chrome พบว่าบนเว็บเพจทั่วไป การใช้หน่วยความจำฮีปของ V8 ลดลงเฉลี่ย 43% สำหรับแอปพลิเคชัน React ยิ่ง component tree มีขนาดใหญ่เท่าไร ผลที่ได้ก็ยิ่งเด่นชัดมากขึ้น

// ผลของ Pointer Compression (Chrome 80+)  
// Before: แต่ละ reference 8 bytes (64-bit)  
// After:  แต่ละ reference 4 bytes (32-bit offset)  
// ผลลัพธ์: V8 heap ลดลง 43%  
  
const obj = {  
  ref1: {},  // 8 bytes -> 4 bytes  
  ref2: {},  // ประหยัดหน่วยความจำ 50%  
  ref3: {}  
};  

4. String Interning

String Interning คือเทคนิคการเพิ่มประสิทธิภาพที่เก็บสตริงที่มีเนื้อหาเหมือนกันไว้ในหน่วยความจำเพียงครั้งเดียวเท่านั้น เป็นแนวคิดคล้ายกับ String Pool ของ Java และ V8 จะทำสิ่งนี้ให้อัตโนมัติ

การทำ intern อัตโนมัติ: สตริงสั้นๆ (โดยทั่วไปไม่เกิน 10 อักขระ) และสตริงที่ถูกใช้งานบ่อยมักถูก V8 ทำ intern ให้อัตโนมัติ ตัวอย่างเช่นสตริงประเภทอีเวนต์อย่าง "click", "hover" แม้จะถูกใช้หลายพันครั้ง ก็จะมีอยู่ในหน่วยความจำเพียงครั้งเดียว

การเพิ่มประสิทธิภาพสำหรับนักพัฒนา: หากนิยามสตริงเป็นค่าคงที่แล้วนำกลับมาใช้ซ้ำ จะช่วยขยายผลของการทำ interning ได้สูงสุด โดยเฉพาะสตริงที่ใช้ซ้ำๆ เช่น Redux action types หรือชื่ออีเวนต์ ควรแปลงให้เป็นค่าคงที่

// การเพิ่มประสิทธิภาพด้วย String Interning  
const EVENT_TYPES = {  
  CLICK: 'click',  
  HOVER: 'hover'  
};  
  
// V8 ทำ intern ให้อัตโนมัติ: สตริงเดียวกันเก็บเพียงครั้งเดียว  
// ใช้ 10,000 ครั้งก็ยังมีเพียง 1 อินสแตนซ์ในหน่วยความจำ  
events.push({ type: EVENT_TYPES.CLICK });  

5. การจัดการหน่วยความจำด้วย WeakMap/WeakSet

WeakMap และ WeakSet คือคอลเลกชันแบบ weak reference ที่ถูกเพิ่มเข้ามาใน ES6 และเป็นเครื่องมือทรงพลังในการป้องกัน memory leak

ปัญหาของ Map ทั่วไป: Map ทั่วไปจะอ้างอิงอ็อบเจ็กต์ที่ใช้เป็นคีย์แบบ strong reference ทำให้แม้อ็อบเจ็กต์นั้นจะไม่จำเป็นอีกต่อไป GC ก็ไม่สามารถเก็บกวาดได้ สิ่งนี้ทำให้เกิด memory leak ร้ายแรงได้ โดยเฉพาะเมื่อใช้ DOM node เป็นคีย์

ทางออกของ WeakMap: WeakMap อ้างอิงอ็อบเจ็กต์คีย์แบบ weak reference ดังนั้นหากไม่มีการอ้างอิงอื่นถึงอ็อบเจ็กต์คีย์นั้น entry ก็จะถูกลบออกโดยอัตโนมัติ ทำให้สามารถสร้างแคชหรือที่เก็บ metadata ได้อย่างปลอดภัย

การใช้งานจริง: ช่วยรับประกันความปลอดภัยด้านหน่วยความจำในการเก็บข้อมูล private ของคอมโพเนนต์ React การจัดการข้อมูลที่เชื่อมกับ DOM node และการสร้างแคชชั่วคราว เป็นต้น

// WeakMap: ปล่อยหน่วยความจำอัตโนมัติ  
const cache = new WeakMap();  
  
// metadata ของ DOM node (ล้างอัตโนมัติ)  
elements.forEach(el => {  
  cache.set(el, { data: 'metadata' });  
  // เมื่อลบ el แคชก็จะถูกล้างอัตโนมัติ  
});  
  
// Map: ต้องลบเองอย่างชัดเจน (เสี่ยง memory leak)  
const map = new Map();  // คง strong reference ไว้  

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

การวัดผลลัพธ์: ผลกระทบจริงของ Orinoco

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

• ก่อนใช้ Orinoco (2016): เวลาหยุดของ GC 10~50ms
• หลังใช้ Orinoco (2019): เวลาหยุดของ GC 2~15ms (ลดลงประมาณ 40~60%)

ยังมีผลลัพธ์อีกด้วยว่า หลังใช้ Orinoco ในสภาพแวดล้อมแบบ SPA เวลาเฉลี่ยในการตอบสนองของหน้าเว็บดีขึ้นราว 18%

แม้ผลลัพธ์เหล่านี้จะน่าทึ่งเพียงพออยู่แล้ว แต่กระบวนทัศน์ใหม่ก็ได้ปรากฏขึ้นอีกครั้ง

WebAssembly และกลยุทธ์การปรับแต่งของ V8: สถาปัตยกรรมรันไทม์

WebAssembly (WASM) เป็นฟอร์แมตไบนารีระดับล่างที่ออกแบบมาเพื่อให้ได้ประสิทธิภาพใกล้เคียง native บนเบราว์เซอร์ ทำให้โค้ดที่เขียนด้วยภาษาอย่าง C++, Rust และ Go สามารถรันบนเบราว์เซอร์ได้ และ V8 ก็มีกลยุทธ์การปรับแต่งที่ซับซ้อนเพื่อรันสิ่งนี้อย่างมีประสิทธิภาพ

1. กลยุทธ์การคอมไพล์หลายชั้น (Tiered Compilation)

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

ทางออก: V8 ใช้การคอมไพล์หลายชั้นกับ WASM เช่นเดียวกับ JavaScript โดย baseline compiler ที่ชื่อว่า Liftoff จะสร้างโค้ดที่พร้อมรันได้อย่างรวดเร็ว และ TurboFan จะเตรียมโค้ดที่ผ่านการปรับแต่งไว้เบื้องหลัง

// WebAssembly แบบคอมไพล์หลายชั้น  
async function loadWasm() {  
  const response = await fetch('module.wasm');  
  // Streaming: คอมไพล์ไปพร้อมกับการดาวน์โหลด  
  const module = await WebAssembly.compileStreaming(response);  
  
  // Liftoff: ~10ms/MB (baseline ที่รวดเร็ว)  
  // TurboFan: ~100ms/function (ปรับแต่งเบื้องหลัง)  
  
  return WebAssembly.instantiate(module, imports);  
}  

2. Dynamic Tiering และการตรวจจับฮอตสปอต

Dynamic Tiering ที่นำมาใช้ตั้งแต่ Chrome 96 จะวิเคราะห์ความถี่ในการรันของฟังก์ชัน WASM แบบไดนามิกเพื่อคัดเลือกเป้าหมายสำหรับการปรับแต่ง เรื่องนี้สำคัญอย่างมากโดยเฉพาะในสภาพแวดล้อมมือถือ เพราะช่วยป้องกันการสิ้นเปลืองแบตเตอรี่จากการปรับแต่งที่ไม่จำเป็น

หลักการทำงาน

• การรันครั้งแรก: ทุกฟังก์ชันจะถูกคอมไพล์ด้วย Liftoff
• การตรวจจับฮอตสปอต: ใช้ execution counter เพื่อตรวจหาฟังก์ชันที่ถูกเรียกบ่อย
• การปรับแต่งแบบเลือกเฉพาะ: คอมไพล์ซ้ำด้วย TurboFan เฉพาะฟังก์ชันที่เกิน threshold (เช่น 1000 ครั้ง)
• การปรับแบบไดนามิก: จูนค่า threshold อัตโนมัติตาม workload

// Dynamic Tiering: ตรวจจับ hot function อัตโนมัติ  
const funcStats = {  
  add: { calls: 0, optimized: false },  
  matrixMultiply: { calls: 0, optimized: false }  
};  
  
// เมื่อเกิน threshold (1000 ครั้ง) จะปรับแต่งด้วย TurboFan  
if (funcStats.matrixMultiply.calls++ > 1000) {  
  // Liftoff -> คอมไพล์ซ้ำเป็น TurboFan  
}  
  
// การใช้ WASM ใน React  
const wasm = await WebAssembly.instantiateStreaming(  
  fetch('module.wasm')  
);  
wasm.instance.exports.processImage(data);  

3. การจัดการหน่วยความจำและการผสานรวมกับ GC

ปัญหาเดิม: เดิมที WebAssembly ใช้เพียงอาร์เรย์ไบต์แบบง่ายที่เรียกว่า Linear Memory ซึ่งเหมาะกับภาษาระดับล่างอย่าง C/C++ แต่ไม่มีประสิทธิภาพเมื่อต้องโต้ตอบกับอ็อบเจ็กต์ของ JavaScript

WasmGC Proposal (Chrome 119+): เพิ่มความสามารถด้าน garbage collection ให้กับ WebAssembly เพื่อให้ใช้ GC ร่วมกับ JavaScript ได้ ส่งผลให้มีข้อดีดังต่อไปนี้

• อ้างอิงข้ามกันได้ระหว่างอ็อบเจ็กต์ JavaScript และ struct ของ WASM
• ไม่ต้องจัดการหน่วยความจำแบบชัดเจน (มี automatic GC โดยไม่ต้องใช้ malloc/free)
• จัดการ circular reference ได้อัตโนมัติ
• มี GC pause time ชุดเดียว ทำให้ประสิทธิภาพคาดการณ์ได้

// การแชร์หน่วยความจำ: Linear Memory  
const memory = new WebAssembly.Memory({  
  initial: 256,   // 16MB  
  maximum: 32768  // 2GB  
});  
  
// การส่งข้อมูลระหว่าง JS <-> WASM  
const view = new Uint8Array(memory.buffer, ptr, size);  
view.set(data);  // JS -> WASM  
  
// WasmGC (Chrome 119+): GC อัตโนมัติ  
// (type $point (struct (field $x f64) (field $y f64)))  
// JS และ WASM ใช้ GC ร่วมกัน  

4. SIMD และการปรับแต่งขั้นสูง

SIMD (Single Instruction, Multiple Data) คือเทคนิคการประมวลผลแบบขนานที่ใช้คำสั่งเดียวจัดการข้อมูลหลายชุดพร้อมกัน V8 รองรับ WebAssembly SIMD เพื่อดึงความสามารถด้าน vector operation ของ CPU มาใช้ได้สูงสุด

ตัวอย่างการเพิ่มประสิทธิภาพ

• การบวกเวกเตอร์: บวกค่า float 4 ตัวพร้อมกันในครั้งเดียว (เร็วขึ้น 4 เท่า)
• การคูณเมทริกซ์: คำนวณเร็วขึ้น 30 เท่ากับเมทริกซ์ขนาด 512x512
• ฟิลเตอร์ภาพ: ทำเอฟเฟกต์ blur และ sharpen แบบเรียลไทม์ได้
• การจำลองฟิสิกส์: ทำ fluid simulation ที่ 60fps ได้

// SIMD: ประมวลผลข้อมูล 4 ชุดพร้อมกัน  
// JavaScript: ประมวลผลทีละ 1 ชุดด้วยลูป  
for (let i = 0; i < arr.length; i++) {  
  result[i] = a[i] + b[i];  // ช้า  
}  
  
// WASM SIMD: ประมวลผลแบบขนานครั้งละ 4 ชุด  
// (f32x4.add (v128.load a) (v128.load b))  
// vector operation เร็วขึ้น 4 เท่า  
  
// ประสิทธิภาพ: JS ~450ms -> WASM ~50ms -> SIMD ~15ms  

5. การแคชโค้ดและการปรับแต่งประสิทธิภาพ

ปัญหาเรื่องต้นทุนการคอมไพล์: โมดูล WASM ขนาดใหญ่ (>
10MB) อาจใช้เวลาคอมไพล์นานหลายวินาที หากต้องคอมไพล์ใหม่ทุกครั้งที่โหลดหน้าเว็บ ประสบการณ์ผู้ใช้จะยิ่งแย่ลง

กลยุทธ์การแคชของ V8

• การแคชโค้ดที่คอมไพล์แล้ว: เก็บ machine code ที่ TurboFan ปรับแต่งแล้วไว้ใน IndexedDB
• การซีเรียลไลซ์โมดูล: บันทึกผลการคอมไพล์ด้วย WebAssembly.Module.serialize()
• การโหลดอย่างรวดเร็ว: หาก cache hit ก็รันได้ทันทีโดยไม่ต้องคอมไพล์
• การจัดการเวอร์ชัน: ทำ cache invalidation ตาม timestamp

// การแคชโค้ด WASM (IndexedDB)  
async function loadWithCache(url) {  
  // 1. ตรวจสอบแคช  
  let module = await cache.get(url);  
  
  if (!module) {  
    // 2. คอมไพล์และจัดเก็บ  
    module = await WebAssembly.compileStreaming(  
      fetch(url)  
    );  
    await cache.store(url, module);  
  }  
  
  return module;  // นำกลับมาใช้ซ้ำโดยไม่ต้องคอมไพล์ใหม่  
}  

6. การวัดประสิทธิภาพจริง

ผลลัพธ์ของเบนช์มาร์ก แสดงให้เห็นถึงความเหนือกว่าของ WebAssembly อย่างชัดเจน ในงานที่เน้นการคำนวณอย่างการคูณเมทริกซ์ สามารถเพิ่มประสิทธิภาพได้ 9-30 เท่าเมื่อเทียบกับ JavaScript

กรณีการใช้งานจริง

• AutoCAD Web: เรนเดอร์ 3D CAD บนเบราว์เซอร์ด้วยประสิทธิภาพระดับเนทีฟ
• Google Earth: เรนเดอร์ข้อมูลแผนที่ 3D ขนาดใหญ่แบบเรียลไทม์
• Figma: สร้างเอนจินกราฟิกเวกเตอร์ด้วย WASM เพื่อให้ตอบสนองได้รวดเร็ว
• Photoshop Web: ประมวลผลฟิลเตอร์และเอฟเฟกต์ภาพด้วยความเร็วระดับเนทีฟ

// เบนช์มาร์กประสิทธิภาพ (การคูณเมทริกซ์ 512x512)  
// JavaScript:     ~450ms  
// WebAssembly:    ~50ms  (เร็วกว่า 9 เท่า)  
// WASM + SIMD:    ~15ms  (เร็วกว่า 30 เท่า)  
  
// ตัวอย่าง React image filter  
const applyFilter = async (imageData) => {  
  // JS filter:   ~50ms  
  // WASM filter: ~5ms (เร็วกว่า 10 เท่า)  
  return wasmFilters[filterType](imageData);  
};  

เทคนิคการปรับแต่ง WebAssembly เหล่านี้ทำงานเสริมกันกับการปรับแต่ง JavaScript ของ V8 และทำให้เกิดประสิทธิภาพระดับเนทีฟในเบราว์เซอร์ได้มากขึ้น JavaScript จะรับผิดชอบ business logic และ UI ส่วน WebAssembly จะรับผิดชอบในส่วนที่วิกฤตต่อประสิทธิภาพ โดยสถาปัตยกรรมแบบไฮบริดลักษณะนี้กำลังกลายเป็นแนวทางที่แพร่หลายมากขึ้นเรื่อย ๆ

กลยุทธ์การปรับแต่งสำหรับโปรดักชันจริง

แพตเทิร์นการปรับแต่งหน่วยความจำในแอประดับขนาดใหญ่

1. การปรับแต่ง Incremental DOM ใน Gmail

// กลยุทธ์อัปเดต DOM แบบค่อยเป็นค่อยไปของ Gmail  
class IncrementalRenderer {  
  constructor() {  
    this.pendingUpdates = new WeakMap();  
    this.updateQueue = [];  
  }  
  
  scheduleUpdate(element, patch) {  
    // อ้างอิงที่เป็นมิตรกับ GC ด้วย WeakMap  
    this.pendingUpdates.set(element, patch);  
    
    // ใช้ช่วงเวลาว่างด้วย requestIdleCallback  
    requestIdleCallback(() => {  
      this.processBatch();  
    }, { timeout: 16 }); // งบเวลา 1 เฟรม  
  }  
  
  processBatch() {  
    const batchSize = 100;  
    for (let i = 0; i < batchSize && this.updateQueue.length; i++) {  
      const update = this.updateQueue.shift();  
      update.apply();  
    }  
  }  
}  

ผลลัพธ์: ความถี่ของ Major GC ลดลง 70%, รักษาอัตราเฟรมเฉลี่ยได้ 95%

2. กลยุทธ์ object pooling ของ Discord

// การทำพูลสำหรับอ็อบเจ็กต์ข้อความ  
class MessagePool {  
  constructor(size = 1000) {  
    this.pool = [];  
    this.activeMessages = new Set();  
    
    // จัดสรรล่วงหน้า  
    for (let i = 0; i < size; i++) {  
      this.pool.push(new Message());  
    }  
  }  
  
  acquire() {  
    let msg = this.pool.pop();  
    if (!msg) {  
      // พูลถูกใช้จนหมด จึงขยายแบบไดนามิก  
      console.warn('Pool expansion triggered');  
      msg = new Message();  
    }  
    this.activeMessages.add(msg);  
    return msg.reset();  
  }  
  
  release(msg) {  
    if (this.activeMessages.delete(msg)) {  
      this.pool.push(msg);  
    }  
  }  
}  

ผลลัพธ์: Young Generation GC ลดลง 85%, การใช้หน่วยความจำลดลง 30%

คู่มือเบนช์มาร์กและการวัดประสิทธิภาพ

เครื่องมือวัดประสิทธิภาพของ V8

// การใช้ Chrome DevTools Performance API  
class V8Profiler {  
  static measureGC() {  
    const obs = new PerformanceObserver((list) => {  
      for (const entry of list.getEntries()) {  
        if (entry.entryType === 'measure' &&   
            entry.detail?.kind === 'gc') {  
          console.log(`GC Type: ${entry.detail.type}`);  
          console.log(`Duration: ${entry.duration}ms`);  
          console.log(`Heap Before: ${entry.detail.usedHeapSizeBefore}`);  
          console.log(`Heap After: ${entry.detail.usedHeapSizeAfter}`);  
        }  
      }  
    });  
    
    obs.observe({ entryTypes: ['measure'] });  
  }  
  
  static getHeapSnapshot() {  
    if (typeof gc !== 'undefined') {  
      gc(); // Force GC  
    }  
    
    return performance.measureUserAgentSpecificMemory();  
  }  
}  

ข้อมูลการวัดจริง

Pointer Compression (Chrome 89)

สภาพแวดล้อมทดสอบ: RAM 8GB, CPU 4 คอร์  
แอปที่วัด: Gmail, Google Docs, YouTube  
  
ผลลัพธ์:  
- V8 Heap: 1.2GB -> 684MB (ลดลง 43%)  
- Renderer Memory: 2.1GB -> 1.68GB (ลดลง 20%)  
- Major GC Time: 45ms -> 38.7ms (ลดลง 14%)  
- FID p95: 24ms -> 19ms  

Orinoco vs Legacy GC

Benchmark: Speedometer 2.0  
  
Legacy (2015):  
- Score: 45 ± 3  
- GC Pause p50: 23ms  
- GC Pause p99: 112ms  
- Total GC Time: 3.2s  
  
Orinoco (2019):  
- Score: 78 ± 2 (ดีขึ้น 73%)  
- GC Pause p50: 2.1ms (ลดลง 91%)  
- GC Pause p99: 14ms (ลดลง 87%)  
- Total GC Time: 0.9s (ลดลง 72%)  

เช็กลิสต์สำหรับโปรดักชัน

// V8 최적화 체크리스트  
const optimizationChecklist = {  
  // 1. Hidden Class 최적화  
  avoidDynamicProperties: true,  
  useConstructorsConsistently: true,  
  
  // 2. 인라인 캐싱  
  avoidPolymorphicCalls: true,  
  limitFunctionTypes: 4,  
  
  // 3. 메모리 관리  
  useObjectPools: true,  
  limitClosureScopes: true,  
  preferTypedArrays: true,  
  
  // 4. GC 트리거 최소화  
  batchDOMUpdates: true,  
  useWeakReferences: true,  
  clearLargeObjects: true  
};  

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

Bounus

ในตอนนี้ก็ยังมีความท้าทายใหม่ ๆ รออยู่

• การผสานรวม WASM ที่ดียิ่งขึ้น: การทำ WasmGC ให้สมบูรณ์ครบถ้วน
• การปรับแต่งสำหรับแมชชีนเลิร์นนิง: การจูนอัตโนมัติแบบอิงแพตเทิร์น
• การใช้ประโยชน์จากฮาร์ดแวร์ใหม่: การปรับแต่งสำหรับ ARM และ RISC-V

แหล่งอ้างอิง

• V8 Official Documentation
• V8 GitHub Repository
• V8 Orinoco Parallel Scavenger
• Jank Busters Part 2: Orinoco
• Pointer Compression in V8
• To Pool or Not to Pool? Revisiting an Old Pattern
• WASM GC Porting
• The story of a V8 performance cliff in React