← All issues

[JSC] Eagerly build AST for likely IIFEs

709e4e7

Source/JavaScriptCore/parser/ParserArena.h

-class ParserArenaRoot {
- ParserArenaRoot(ParserArena&&);
- ParserArena m_arena;
+class ParserArenaRoot {
+ explicit ParserArenaRoot(Ref<ParserArena>&&);
+ Ref<ParserArena> m_arena;

JSC's parser uses a two-phase strategy: a fast initial syntax check skips full AST construction, and a full AST is built on-demand when a function compiles. IIFEs break this — they are called immediately, making the initial scan pure overhead. This commit adds a heuristic: when function is preceded by ( or !, the parser eagerly builds a full AST and stores it in a new EagerIIFERegistry keyed by source offset. Subsequent Parser::parse() invocations check the registry first and skip re-parsing on a hit.

The supporting refactor moves ParserArena ownership from unique (each ParserArenaRoot owned its arena) to ref-counted shared (Ref<ParserArena>), because an eagerly-built IIFE FunctionNode must outlive the arena of the outer parse that triggered it.

IIFE-heavy code — every CommonJS module wrapper, many legacy bundles — gets a parse-time win, and the arena lifetime refactor is a non-trivial change to a foundational parser data structure.

🔒

The arena ownership refactor and new AST cache introduce lifetime and state-restoration edge cases worth auditing.

Subscribe to read more