V8 的終極優化編譯器 Turbofan，是少數採用節點之海 (Sea of Nodes, SoN)的大規模生產編譯器之一。然而，自從大約三年前，我們開始逐步淘汰節點之海，轉而使用更傳統的控制流圖 (CFG) 中間表示 (IR)，我們將其命名為 Turboshaft。目前為止，Turbofan 的整個 JavaScript 後端已完全採用了 Turboshaft，而 WebAssembly 在其整個管線中也完全使用了 Turboshaft。Turbofan 的兩個部分仍然使用一些節點之海：內建管線（我們正在逐步用 Turboshaft 替代）以及 JavaScript 管線的前端（我們正用另一個基於 CFG 的 IR，名為 Maglev 替代）。這篇博文將解釋我們放棄節點之海的原因。
當我編譯一個使用不到 4GB RAM 的程式時，使用 64 位元指標是完全荒謬的。在結構體中出現這些指標值時，它們不僅浪費了一半的記憶體，還有效地丟掉了一半的快取。
自 v8 v7.2 開始，類字段已在 V8 中推出，而私有類方法自 v8.4 啟用。隨著相關提案於 2021 年達到第 4 階段，針對 V8 中新類特性的支持改進工作開始啟動 —— 在此之前，這些特性的採用主要受到兩個問題的影響：
雖然這篇文章的標題可能暗示我們要深入探討關於油底殼的書籍集合——考慮到油底殼的建造規範，這是一個有著驚人文獻的話題——但實際上我們會更深入探討 Oilpan，一個由 V8 作為圖書館自 V8 v9.4 起托管的 C++ 垃圾回收器。
JavaScript 允許以與期望的參數數量不同的參數數量調用函數，即可以傳遞比聲明的正式參數數量更少或更多的參數。前者稱為低於應用，後者稱為超量應用。
從 v8.8 開始，V8 提供一個新的實驗性無回溯正規表示法引擎（除了現有的 Irregexp 引擎以外），該引擎保證相對於主串大小以線性時間執行。實驗性引擎可通過下面的功能標誌開啟。
Slack 追蹤是一種給新對象一個 比實際使用更大的初始大小 的方法，便於快速新增屬性。然後，經過一段時間後，將未使用的空間 神奇地返回到系統。很棒吧？
我們之前已多次撰文討論過JavaScript 的垃圾回收、文件物件模型 (DOM) 及其在 V8 中的實現及優化。然而，Chromium 中並不全是 JavaScript，瀏覽器本身及 V8 所嵌套的 Blink 渲染引擎大多數使用 C++ 編寫。JavaScript 可用於操作 DOM，而後者由渲染管線進行處理。
記憶體和效能之間總是一場持續的鬥爭。作為使用者，我們希望事情既快速又盡可能少地消耗記憶體。不幸的是，通常提升效能會以增加記憶體消耗為代價（反之亦然）。
在其默認配置中，V8 在正則表達式首次執行時將其編譯為本地代碼。作為我們對JIT-less V8工作的的一部分，我們引入了一個正則表達式解釋器。解釋正則表達式的優勢是使用更少的內存，但代價是性能下降。在這篇博客文章中，我們描述了如何在減少性能損失的同時利用解釋正則表達式的優勢。