It makes V8 generate source-location metadata during the first compilation, instead of skipping it and potentially recompiling the function later to recover it. System tests can win because they exercise stack traces and browser instrumentation far more than ordinary browsing does.
I checked the local V8 checkout at ~/scratch/2026-10-14-v8-rerank/v8, commit d353072a3566 (29 April 2026).
What the flag actually changes
Chrome’s argument is:
--js-flags=--no-enable-lazy-source-positions
A source-position table maps bytecode offsets back to positions in the JavaScript source. V8 uses that to produce things like application.js:123:45 in stack traces and console messages. It is not a source map.
The flag definition describes the default lazy behaviour:
"skip generating source positions during initial compile but "
"regenerate when actually required"
Disabling that laziness flips this compilation setting in src/parsing/parse-info.cc:35:
set_collect_source_positions(!v8_flags.enable_lazy_source_positions ||
isolate->NeedsDetailedOptimizedCodeLineInfo());
So the double negative matters: this flag collects more metadata upfront, not less. It does not disable lazy function compilation or the JIT.
Why avoiding laziness can be faster
Recovering the omitted metadata is surprisingly expensive.
Compiler::CollectSourcePositions does the following:
- Marks the operation as a reparse.
- Parses the function’s source again.
- Runs the interpreter’s bytecode-generation machinery again.
- Attaches the resulting source-position table to the existing bytecode.
This happens synchronously on the isolate’s thread; the code explicitly disables spawning parallel compilation tasks for this job.
Conceptually:
| Default: lazy positions | With your flag |
|---|---|
| Parse + compile without positions | Parse + compile with positions |
| Later need a stack location | Later need a stack location |
| Reparse + run bytecode generation again | Read the existing table |
You are avoiding a second compiler pass, rather than merely moving the same amount of work earlier.
Why system tests expose it
Console logging is enough; the tests do not have to be failing.
In src/inspector/v8-console.cc, ordinary console calls capture a stack trace. The inspector normally captures the top frame; with the Runtime agent enabled, it can capture a deeper stack. Resolving those frames’ locations eventually calls EnsureSourcePositionsAvailable, which triggers the reparse if the table is missing.
Other triggers include reading Error().stack, exception reporting, and debugger activity.
Browser system tests combine several unfriendly conditions:
- Automation and console/error collection create demand for source locations.
- Development builds often log warnings and deprecations.
- Repeated navigation and fresh contexts repeatedly encounter newly compiled functions.
That can turn the default optimisation—“don’t generate metadata we probably won’t need”—into “skip it, then pay to reconstruct it anyway.”
The table is cached once collected, so this is not a recompile on every log message. The cost is generally the first demand per function’s bytecode, repeated as new code is compiled or recreated.
Bottom line: this trades extra initial compilation work and metadata memory for fewer synchronous recompilation stalls during the test. The source establishes the mechanism; without a trace of your test run, it doesn’t establish how much of your particular speedup comes from console logging versus other stack-location requests.