From b4fce5fe1c3c167629aa3c8359527c816d48de96 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Zasso?= Date: Mon, 27 Jul 2026 15:35:48 +0200 Subject: [PATCH 01/34] deps: update V8 to 14.9.207.39 --- deps/v8/.git-blame-ignore-revs | 3 + deps/v8/.gitignore | 5 + deps/v8/.gn | 8 +- deps/v8/.vpython3 | 12 +- deps/v8/.ycm_extra_conf.py | 6 +- deps/v8/AUTHORS | 8 +- deps/v8/BUILD.bazel | 101 +- deps/v8/BUILD.gn | 399 +- deps/v8/COMMON_OWNERS | 1 + deps/v8/DEPS | 314 +- deps/v8/MODULE.bazel | 10 +- deps/v8/OWNERS | 1 + deps/v8/README.md | 2 +- deps/v8/RISCV_OWNERS | 2 +- deps/v8/SECURITY.md | 8 + deps/v8/WATCHLISTS | 6 + deps/v8/agents/.style.mdformat | 1 + deps/v8/agents/.vpython3 | 6 + deps/v8/agents/OWNERS | 1 + deps/v8/agents/README.md | 33 + deps/v8/agents/agents/builder/agent.json | 5 + deps/v8/agents/agents/builder/config.yaml | 11 + deps/v8/agents/agents/debugger/agent.json | 5 + deps/v8/agents/agents/debugger/config.yaml | 12 + deps/v8/agents/agents/researcher/agent.json | 5 + deps/v8/agents/agents/researcher/config.yaml | 10 + deps/v8/agents/agents/tester/agent.json | 5 + deps/v8/agents/agents/tester/config.yaml | 11 + deps/v8/agents/prompts/README.md | 27 + .../{GEMINI.md => agents/prompts/common.md} | 62 - deps/v8/agents/prompts/templates/README.md | 17 + deps/v8/agents/prompts/templates/modular.md | 59 + deps/v8/agents/rules/debugging.md | 49 + deps/v8/agents/rules/execution-constraints.md | 17 + deps/v8/agents/rules/framework.md | 17 + deps/v8/agents/rules/git-cl.md | 47 + deps/v8/agents/rules/git-commit.md | 28 + deps/v8/agents/rules/torque.md | 17 + deps/v8/agents/rules/v8-best-practices.md | 31 + deps/v8/agents/rules/writing-skills.md | 132 + deps/v8/agents/scripts/analyze_brain.py | 59 + deps/v8/agents/scripts/cleanup_git_task.sh | 19 + deps/v8/agents/scripts/get_recent_commits.py | 60 + .../agents/scripts/install_for_gemini_cli.py | 91 + deps/v8/agents/scripts/install_for_jetski.py | 70 + deps/v8/agents/scripts/new_git_task.sh | 19 + deps/v8/agents/skills/README.md | 30 + .../agent-evaluation-framework/SKILL.md | 47 + .../skills/agent-self-improvement/SKILL.md | 55 + deps/v8/agents/skills/clangd-setup/SKILL.md | 40 + deps/v8/agents/skills/crossbench/SKILL.md | 77 + .../skills/doc-invalidation-checker/SKILL.md | 35 + deps/v8/agents/skills/ecmascript/SKILL.md | 124 + .../v8/agents/skills/env-abstraction/SKILL.md | 43 + .../skills/header-cycle-breaker/SKILL.md | 69 + deps/v8/agents/skills/jsvu/SKILL.md | 30 + deps/v8/agents/skills/orchestrator/SKILL.md | 92 + .../skills/subagent-env-passing/SKILL.md | 33 + deps/v8/agents/skills/torque/SKILL.md | 72 + .../v8/agents/skills/v8-ciderg-paths/SKILL.md | 18 + deps/v8/agents/skills/v8-commands/SKILL.md | 43 + deps/v8/agents/skills/v8-log/SKILL.md | 133 + .../skills/v8-poc-classification/SKILL.md | 26 + deps/v8/agents/skills/v8-profile/SKILL.md | 76 + deps/v8/agents/skills/v8-setup/SKILL.md | 53 + deps/v8/agents/skills/v8-structure/SKILL.md | 53 + deps/v8/agents/skills/v8-testing/SKILL.md | 57 + .../agents/skills/v8-understanding/SKILL.md | 38 + deps/v8/agents/skills/v8-workflow/SKILL.md | 35 + .../agents/skills/workflow-debugging/SKILL.md | 102 + .../workflow-general-debugging/SKILL.md | 41 + deps/v8/agents/skills/workflow-perf/SKILL.md | 122 + .../scripts/upload_and_pinpoint.py | 73 + .../skills/workflow_gerrit_fix/SKILL.md | 56 + deps/v8/bazel/defs.bzl | 3 +- deps/v8/bazel/patches/BUILD.bazel | 1 + deps/v8/bazel/patches/highway_rules_cc.patch | 8 + deps/v8/bazel/toolchain/libcxx_repository.bzl | 19 +- deps/v8/docs/OWNERS | 2 +- deps/v8/docs/README.md | 91 +- deps/v8/docs/api.md | 45 + deps/v8/docs/become-committer.md | 46 + deps/v8/docs/benchmarks.md | 54 + deps/v8/docs/blink-layout-tests.md | 16 + deps/v8/docs/build-gn.md | 134 + deps/v8/docs/build.md | 63 + deps/v8/docs/builtin-functions.md | 9 + deps/v8/docs/builtins/architecture.md | 67 + deps/v8/docs/builtins/torque-tutorial.md | 126 + .../v8/docs/codegen/assembler-architecture.md | 58 + deps/v8/docs/codegen/code-stub-assembler.md | 40 + deps/v8/docs/codegen/csa-tutorial.md | 232 ++ deps/v8/docs/committer-responsibility.md | 42 + deps/v8/docs/compile-arm64.md | 86 + .../concurrency-and-background-compilation.md | 62 + .../maglev/compiler-maglev-regalloc.md | 77 + .../docs/compiler/maglev/compiler-maglev.md | 115 + .../compiler/sparkplug/compiler-sparkplug.md | 58 + .../compiler/turbofan/compiler-turbofan.md | 97 + .../compiler-turboshaft-copying-approach.md | 49 + .../turboshaft/compiler-turboshaft-ir.md | 87 + .../compiler-turboshaft-reducers.md | 85 + .../turboshaft/compiler-turboshaft.md | 78 + deps/v8/docs/compiler/why-cfg.md | 63 + deps/v8/docs/contribute.md | 41 + deps/v8/docs/cross-compile-arm.md | 170 + deps/v8/docs/cross-compile-ios.md | 52 + deps/v8/docs/d8.md | 80 + deps/v8/docs/debug-arm.md | 521 +++ deps/v8/docs/design-review-guidelines.md | 148 + deps/v8/docs/embed.md | 438 +++ deps/v8/docs/evaluate-code-coverage.md | 35 + deps/v8/docs/feature-launch-process.md | 83 + deps/v8/docs/flake-bisect.md | 72 + deps/v8/docs/gdb-jit.md | 65 + deps/v8/docs/gdb.md | 40 + deps/v8/docs/heap/compaction.md | 43 + deps/v8/docs/heap/garbage-collection.md | 72 + deps/v8/docs/heap/handles.md | 60 + deps/v8/docs/heap/heap-overview.md | 57 + deps/v8/docs/heap/marking-and-sweeping.md | 92 + deps/v8/docs/heap/objects-and-maps.md | 85 + deps/v8/docs/heap/pointer-compression.md | 89 + deps/v8/docs/heap/pointer-tagging.md | 85 + deps/v8/docs/heap/roots.md | 46 + deps/v8/docs/heap/zone-allocator.md | 55 + deps/v8/docs/i18n.md | 39 + deps/v8/docs/ide-setup.md | 95 + deps/v8/docs/index.md | 79 + deps/v8/docs/inspector.md | 70 + .../docs/interpreter/interpreter-ignition.md | 150 + deps/v8/docs/javascript-overview.md | 104 + deps/v8/docs/linux-perf.md | 123 + deps/v8/docs/memory-leaks.md | 53 + deps/v8/docs/merge-patch.md | 81 + deps/v8/docs/node-integration.md | 71 + .../descriptor-and-transition-arrays.md | 133 + deps/v8/docs/objects/fields-and-elements.md | 147 + deps/v8/docs/objects/lookup-iterator.md | 87 + deps/v8/docs/objects/strings.md | 91 + deps/v8/docs/official-support.md | 22 + deps/v8/docs/overview.md | 53 + .../parsing/lazy-parsing-and-preparser.md | 76 + deps/v8/docs/parsing/parser-and-ast.md | 60 + deps/v8/docs/ports.md | 29 + deps/v8/docs/profile-chromium.md | 59 + deps/v8/docs/profile.md | 172 + deps/v8/docs/rcs.md | 64 + deps/v8/docs/regexp/architecture.md | 39 + deps/v8/docs/release-process.md | 68 + deps/v8/docs/respectful-code.md | 53 + deps/v8/docs/runtime/deoptimization.md | 123 + deps/v8/docs/runtime/exception-handling.md | 89 + deps/v8/docs/runtime/function-architecture.md | 240 ++ .../v8/docs/runtime/hidden-classes-and-ics.md | 128 + .../docs/runtime/hidden-classes-tutorial.md | 236 ++ .../v8/docs/runtime/scopes-and-scope-infos.md | 95 + deps/v8/docs/runtime/stack-walking.md | 84 + deps/v8/docs/runtime/tiering.md | 107 + deps/v8/docs/sandbox/architecture.md | 79 + deps/v8/docs/security/reproducing-bugs.md | 26 + deps/v8/docs/security/triaging.md | 128 + deps/v8/docs/snapshot/architecture.md | 87 + deps/v8/docs/source-code.md | 162 + deps/v8/docs/stack-trace-api.md | 190 + deps/v8/docs/test.md | 109 + deps/v8/docs/torque/architecture.md | 103 + deps/v8/docs/torque/user-manual.md | 737 ++++ deps/v8/docs/trace.md | 46 + deps/v8/docs/triage-issues.md | 35 + deps/v8/docs/untrusted-code-mitigations.md | 40 + deps/v8/docs/version-numbers.md | 54 + deps/v8/docs/viewer/.gitignore | 2 + deps/v8/docs/viewer/generator.js | 185 + deps/v8/docs/viewer/index.html | 607 +++ deps/v8/docs/viewer/package-lock.json | 847 +++++ deps/v8/docs/viewer/package.json | 16 + deps/v8/docs/viewer/server.js | 187 + deps/v8/docs/wasm-shipping-checklist.md | 206 ++ deps/v8/docs/wasm/architecture.md | 93 + deps/v8/docs/webassembly-opcode.md | 437 +++ deps/v8/gni/OWNERS | 2 - deps/v8/gni/cluster_build.gni | 221 ++ deps/v8/gni/release_branch_toggle.gni | 7 - deps/v8/gni/v8.gni | 56 +- deps/v8/include/cppgc/heap.h | 19 +- deps/v8/include/cppgc/visitor.h | 11 +- deps/v8/include/v8-array-buffer.h | 21 - deps/v8/include/v8-cppgc.h | 5 + deps/v8/include/v8-debug.h | 25 +- deps/v8/include/v8-external.h | 7 - deps/v8/include/v8-function-callback.h | 10 +- deps/v8/include/v8-initialization.h | 41 + deps/v8/include/v8-inspector.h | 14 +- deps/v8/include/v8-internal.h | 285 +- deps/v8/include/v8-isolate.h | 5 +- deps/v8/include/v8-message.h | 6 +- deps/v8/include/v8-object.h | 42 +- deps/v8/include/v8-persistent-handle.h | 12 +- deps/v8/include/v8-platform.h | 10 + deps/v8/include/v8-primitive-object.h | 2 +- deps/v8/include/v8-primitive.h | 48 +- deps/v8/include/v8-profiler.h | 26 +- deps/v8/include/v8-promise.h | 4 +- deps/v8/include/v8-sandbox.h | 14 +- deps/v8/include/v8-script.h | 17 +- deps/v8/include/v8-template.h | 302 +- deps/v8/include/v8-value-serializer-version.h | 2 +- deps/v8/include/v8-version.h | 6 +- deps/v8/include/v8-wasm.h | 4 + deps/v8/include/v8config.h | 4 - deps/v8/infra/mb/mb_config.pyl | 52 +- deps/v8/infra/testing/builders.pyl | 248 +- deps/v8/samples/hello-world.cc | 5 +- deps/v8/samples/process.cc | 22 +- deps/v8/samples/shell.cc | 5 +- deps/v8/src/DEPS | 1 + deps/v8/src/api/api-arguments-inl.h | 31 +- deps/v8/src/api/api-arguments.h | 7 + deps/v8/src/api/api-natives.cc | 4 +- deps/v8/src/api/api.cc | 589 +-- deps/v8/src/api/api.h | 3 +- deps/v8/src/asmjs/asm-js.cc | 8 +- deps/v8/src/asmjs/asm-parser.cc | 1 + deps/v8/src/asmjs/asm-parser.h | 2 + deps/v8/src/ast/ast-value-factory.cc | 34 +- deps/v8/src/ast/ast-value-factory.h | 6 +- deps/v8/src/ast/ast.cc | 184 +- deps/v8/src/ast/ast.h | 77 +- deps/v8/src/ast/modules.cc | 4 +- deps/v8/src/ast/prettyprinter.cc | 59 +- deps/v8/src/ast/scopes.cc | 593 ++- deps/v8/src/ast/scopes.h | 95 +- deps/v8/src/ast/variables.h | 20 +- deps/v8/src/base/cpu.cc | 1097 ------ deps/v8/src/base/cpu/cpu-arm.cc | 474 +++ deps/v8/src/base/cpu/cpu-helper.h | 44 + deps/v8/src/base/cpu/cpu-loong64.cc | 60 + deps/v8/src/base/cpu/cpu-mips64.cc | 43 + deps/v8/src/base/cpu/cpu-ppc.cc | 92 + deps/v8/src/base/cpu/cpu-riscv.cc | 84 + .../base/cpu/cpu-s390.cc} | 14 +- deps/v8/src/base/cpu/cpu-x86.cc | 246 ++ deps/v8/src/base/cpu/cpu.cc | 226 ++ deps/v8/src/base/{ => cpu}/cpu.h | 176 +- deps/v8/src/base/enum-set.h | 3 +- deps/v8/src/base/flags.h | 102 +- deps/v8/src/base/ieee754.cc | 59 - deps/v8/src/base/ieee754.h | 4 +- deps/v8/src/base/logging.cc | 33 +- deps/v8/src/base/logging.h | 75 +- deps/v8/src/base/macros.h | 68 +- .../base/platform/memory-protection-key.cc | 10 +- deps/v8/src/base/platform/platform-aix.cc | 44 +- deps/v8/src/base/platform/platform-posix.cc | 29 +- deps/v8/src/base/platform/platform-win32.cc | 53 +- deps/v8/src/base/platform/platform.h | 14 + deps/v8/src/base/platform/time.cc | 2 +- deps/v8/src/base/sanitizer/asan.h | 10 + deps/v8/src/base/small-map.h | 28 +- deps/v8/src/base/small-vector.h | 57 +- deps/v8/src/base/strong-alias.h | 38 +- deps/v8/src/base/timezone-cache.h | 4 +- deps/v8/src/base/vector.h | 122 +- .../baseline/arm/baseline-assembler-arm-inl.h | 39 +- .../arm64/baseline-assembler-arm64-inl.h | 37 +- deps/v8/src/baseline/baseline-assembler.h | 3 +- .../src/baseline/baseline-batch-compiler.cc | 16 +- .../v8/src/baseline/baseline-batch-compiler.h | 4 +- deps/v8/src/baseline/baseline-compiler.cc | 182 +- deps/v8/src/baseline/baseline-compiler.h | 7 +- .../src/baseline/bytecode-offset-iterator.cc | 4 +- .../src/baseline/bytecode-offset-iterator.h | 9 +- .../ia32/baseline-assembler-ia32-inl.h | 31 +- .../loong64/baseline-assembler-loong64-inl.h | 39 +- .../mips64/baseline-assembler-mips64-inl.h | 39 +- .../baseline/ppc/baseline-assembler-ppc-inl.h | 39 +- .../riscv/baseline-assembler-riscv-inl.h | 39 +- .../s390/baseline-assembler-s390-inl.h | 48 +- .../baseline/x64/baseline-assembler-x64-inl.h | 38 +- deps/v8/src/bigint/DEPS | 4 + deps/v8/src/bigint/bigint-inl.h | 1426 +++++++ deps/v8/src/bigint/bigint-internal.cc | 191 +- deps/v8/src/bigint/bigint-internal.h | 69 +- deps/v8/src/bigint/bigint.h | 472 +-- deps/v8/src/bigint/bitwise.cc | 346 -- deps/v8/src/bigint/digit-arithmetic.h | 197 - deps/v8/src/bigint/div-barrett.cc | 36 +- deps/v8/src/bigint/div-burnikel.cc | 40 +- deps/v8/src/bigint/div-helpers-inl.h | 165 + deps/v8/src/bigint/div-helpers.cc | 68 - deps/v8/src/bigint/div-helpers.h | 82 - deps/v8/src/bigint/div-schoolbook.cc | 180 +- deps/v8/src/bigint/fromstring.cc | 28 +- deps/v8/src/bigint/mul-fft.cc | 114 +- deps/v8/src/bigint/mul-karatsuba.cc | 32 +- deps/v8/src/bigint/mul-schoolbook.cc | 97 - deps/v8/src/bigint/mul-toom.cc | 8 +- deps/v8/src/bigint/tostring.cc | 67 +- deps/v8/src/bigint/util.h | 36 - deps/v8/src/bigint/vector-arithmetic-inl.h | 59 + deps/v8/src/bigint/vector-arithmetic.cc | 144 - deps/v8/src/bigint/vector-arithmetic.h | 63 - deps/v8/src/builtins/accessors.cc | 69 +- deps/v8/src/builtins/accessors.h | 7 +- deps/v8/src/builtins/arm/builtins-arm.cc | 219 +- deps/v8/src/builtins/arm64/builtins-arm64.cc | 249 +- deps/v8/src/builtins/array-copywithin.tq | 2 +- deps/v8/src/builtins/array-every.tq | 2 +- deps/v8/src/builtins/array-filter.tq | 2 +- deps/v8/src/builtins/array-find.tq | 2 +- deps/v8/src/builtins/array-findindex.tq | 2 +- deps/v8/src/builtins/array-flat.tq | 344 +- deps/v8/src/builtins/array-foreach.tq | 2 +- deps/v8/src/builtins/array-from.tq | 2 +- deps/v8/src/builtins/array-isarray.tq | 2 +- deps/v8/src/builtins/array-join.tq | 74 +- deps/v8/src/builtins/array-lastindexof.tq | 7 +- deps/v8/src/builtins/array-map.tq | 10 +- deps/v8/src/builtins/array-of.tq | 2 +- deps/v8/src/builtins/array-reduce-right.tq | 2 +- deps/v8/src/builtins/array-reduce.tq | 2 +- deps/v8/src/builtins/array-reverse.tq | 2 +- deps/v8/src/builtins/array-shift.tq | 6 +- deps/v8/src/builtins/array-slice.tq | 43 +- deps/v8/src/builtins/array-some.tq | 2 +- deps/v8/src/builtins/array-splice.tq | 4 +- deps/v8/src/builtins/array-to-sorted.tq | 35 +- deps/v8/src/builtins/array-unshift.tq | 2 +- deps/v8/src/builtins/array.tq | 17 +- deps/v8/src/builtins/arraybuffer.tq | 16 +- deps/v8/src/builtins/base.tq | 38 +- deps/v8/src/builtins/boolean.tq | 4 +- deps/v8/src/builtins/builtins-array-gen.cc | 69 +- deps/v8/src/builtins/builtins-array-gen.h | 2 +- deps/v8/src/builtins/builtins-array.cc | 149 +- deps/v8/src/builtins/builtins-arraybuffer.cc | 42 +- .../builtins/builtins-async-function-gen.cc | 124 +- deps/v8/src/builtins/builtins-async-gen.cc | 145 +- deps/v8/src/builtins/builtins-async-gen.h | 14 + .../builtins/builtins-async-generator-gen.cc | 148 +- .../builtins/builtins-async-iterator-gen.cc | 19 +- deps/v8/src/builtins/builtins-bigint-gen.cc | 8 +- deps/v8/src/builtins/builtins-bigint-gen.h | 62 +- deps/v8/src/builtins/builtins-bigint.tq | 69 +- deps/v8/src/builtins/builtins-call-gen.cc | 57 +- deps/v8/src/builtins/builtins-call-gen.h | 2 +- deps/v8/src/builtins/builtins-callsite.cc | 56 +- .../src/builtins/builtins-collections-gen.cc | 88 +- .../src/builtins/builtins-constructor-gen.cc | 43 +- deps/v8/src/builtins/builtins-dataview.cc | 13 +- deps/v8/src/builtins/builtins-date-gen.cc | 30 +- deps/v8/src/builtins/builtins-date.cc | 10 +- deps/v8/src/builtins/builtins-definitions.h | 506 +-- deps/v8/src/builtins/builtins-function.cc | 9 +- .../v8/src/builtins/builtins-generator-gen.cc | 28 +- deps/v8/src/builtins/builtins-global-gen.cc | 4 +- deps/v8/src/builtins/builtins-inl.h | 4 +- deps/v8/src/builtins/builtins-internal-gen.cc | 134 +- deps/v8/src/builtins/builtins-intl-gen.cc | 4 + deps/v8/src/builtins/builtins-intl.cc | 107 +- deps/v8/src/builtins/builtins-iterator-gen.cc | 120 + deps/v8/src/builtins/builtins-iterator-gen.h | 16 +- deps/v8/src/builtins/builtins-iterator-inl.h | 359 +- deps/v8/src/builtins/builtins-iterator.h | 16 +- deps/v8/src/builtins/builtins-math.cc | 34 +- .../builtins/builtins-microtask-queue-gen.cc | 192 +- deps/v8/src/builtins/builtins-number-gen.cc | 414 +-- deps/v8/src/builtins/builtins-number-tsa.cc | 10 +- deps/v8/src/builtins/builtins-object-gen.cc | 75 +- deps/v8/src/builtins/builtins-object.cc | 11 +- deps/v8/src/builtins/builtins-promise-gen.cc | 9 +- deps/v8/src/builtins/builtins-promise.h | 8 +- deps/v8/src/builtins/builtins-proxy-gen.cc | 3 +- deps/v8/src/builtins/builtins-regexp-gen.cc | 220 +- deps/v8/src/builtins/builtins-regexp-gen.h | 3 + deps/v8/src/builtins/builtins-regexp.cc | 8 +- .../src/builtins/builtins-shadow-realm-gen.cc | 8 +- deps/v8/src/builtins/builtins-shared-array.cc | 2 +- .../builtins-sharedarraybuffer-gen.cc | 155 +- .../builtins/builtins-sharedarraybuffer.cc | 2 +- deps/v8/src/builtins/builtins-string-gen.cc | 79 +- deps/v8/src/builtins/builtins-string-gen.h | 2 +- .../v8/src/builtins/builtins-string-tsa-inl.h | 7 +- deps/v8/src/builtins/builtins-string-tsa.cc | 2 +- deps/v8/src/builtins/builtins-string.cc | 9 +- deps/v8/src/builtins/builtins-string.tq | 22 +- deps/v8/src/builtins/builtins-struct.cc | 20 +- deps/v8/src/builtins/builtins-symbol.cc | 8 +- deps/v8/src/builtins/builtins-temporal.cc | 520 ++- deps/v8/src/builtins/builtins-trace.cc | 12 +- .../src/builtins/builtins-typed-array-gen.cc | 26 +- deps/v8/src/builtins/builtins-typed-array.cc | 7 +- deps/v8/src/builtins/builtins-wasm-gen.cc | 89 +- deps/v8/src/builtins/builtins.cc | 54 +- deps/v8/src/builtins/builtins.h | 20 + deps/v8/src/builtins/cast.tq | 13 +- .../src/builtins/constants-table-builder.cc | 16 +- deps/v8/src/builtins/constructor.tq | 4 +- deps/v8/src/builtins/conversion.tq | 2 +- deps/v8/src/builtins/generator.tq | 43 + deps/v8/src/builtins/ia32/builtins-ia32.cc | 314 +- deps/v8/src/builtins/iterator-helpers.tq | 739 +++- deps/v8/src/builtins/iterator.tq | 25 + deps/v8/src/builtins/js-to-js.tq | 147 - deps/v8/src/builtins/js-to-wasm.tq | 62 +- .../src/builtins/loong64/builtins-loong64.cc | 259 +- deps/v8/src/builtins/math.tq | 72 +- .../v8/src/builtins/mips64/builtins-mips64.cc | 176 +- deps/v8/src/builtins/number.tq | 16 +- deps/v8/src/builtins/object.tq | 6 +- deps/v8/src/builtins/ppc/builtins-ppc.cc | 282 +- deps/v8/src/builtins/profile-data-reader.cc | 27 +- deps/v8/src/builtins/profile-data-reader.h | 7 +- .../builtins/promise-abstract-operations.tq | 88 +- deps/v8/src/builtins/promise-all.tq | 13 +- deps/v8/src/builtins/promise-any.tq | 2 +- deps/v8/src/builtins/promise-misc.tq | 6 +- deps/v8/src/builtins/proxy-constructor.tq | 6 +- deps/v8/src/builtins/proxy-delete-property.tq | 2 +- deps/v8/src/builtins/proxy-get-property.tq | 4 +- .../v8/src/builtins/proxy-get-prototype-of.tq | 4 +- deps/v8/src/builtins/proxy-has-property.tq | 4 +- deps/v8/src/builtins/proxy-is-extensible.tq | 4 +- .../src/builtins/proxy-prevent-extensions.tq | 2 +- deps/v8/src/builtins/proxy-revocable.tq | 2 +- deps/v8/src/builtins/proxy-revoke.tq | 2 +- deps/v8/src/builtins/proxy-set-property.tq | 4 +- .../v8/src/builtins/proxy-set-prototype-of.tq | 2 +- deps/v8/src/builtins/reflect.tq | 2 +- deps/v8/src/builtins/regexp-exec.tq | 2 +- deps/v8/src/builtins/regexp-match-all.tq | 4 +- deps/v8/src/builtins/regexp-match.tq | 10 +- deps/v8/src/builtins/regexp-replace.tq | 7 +- deps/v8/src/builtins/regexp-search.tq | 2 +- deps/v8/src/builtins/regexp-source.tq | 2 +- deps/v8/src/builtins/regexp-split.tq | 2 +- deps/v8/src/builtins/regexp-test.tq | 2 +- deps/v8/src/builtins/regexp.tq | 26 +- deps/v8/src/builtins/riscv/builtins-riscv.cc | 315 +- deps/v8/src/builtins/s390/builtins-s390.cc | 236 +- .../src/builtins/setup-builtins-internal.cc | 8 +- deps/v8/src/builtins/string-endswith.tq | 2 +- deps/v8/src/builtins/string-html.tq | 28 +- deps/v8/src/builtins/string-iterator.tq | 4 +- deps/v8/src/builtins/string-pad.tq | 4 +- deps/v8/src/builtins/string-repeat.tq | 2 +- deps/v8/src/builtins/string-slice.tq | 4 +- deps/v8/src/builtins/string-startswith.tq | 2 +- deps/v8/src/builtins/string-substr.tq | 2 +- deps/v8/src/builtins/string-substring.tq | 2 +- deps/v8/src/builtins/string-trim.tq | 2 +- deps/v8/src/builtins/superspread.h | 39 + deps/v8/src/builtins/symbol.tq | 8 +- .../builtins/typed-array-createtypedarray.tq | 12 +- deps/v8/src/builtins/typed-array-entries.tq | 2 +- deps/v8/src/builtins/typed-array-every.tq | 4 +- deps/v8/src/builtins/typed-array-filter.tq | 4 +- deps/v8/src/builtins/typed-array-find.tq | 4 +- deps/v8/src/builtins/typed-array-findindex.tq | 2 +- deps/v8/src/builtins/typed-array-foreach.tq | 2 +- deps/v8/src/builtins/typed-array-from.tq | 2 +- deps/v8/src/builtins/typed-array-keys.tq | 2 +- deps/v8/src/builtins/typed-array-of.tq | 2 +- deps/v8/src/builtins/typed-array-reduce.tq | 2 +- .../src/builtins/typed-array-reduceright.tq | 4 +- deps/v8/src/builtins/typed-array-slice.tq | 2 +- deps/v8/src/builtins/typed-array-some.tq | 2 +- deps/v8/src/builtins/typed-array-sort.tq | 2 +- deps/v8/src/builtins/typed-array-values.tq | 2 +- deps/v8/src/builtins/typed-array-with.tq | 36 +- deps/v8/src/builtins/typed-array.tq | 2 +- .../src/builtins/wasm-interpreter-wrappers.tq | 424 +++ deps/v8/src/builtins/wasm-strings.tq | 118 +- deps/v8/src/builtins/wasm-to-js.tq | 10 +- deps/v8/src/builtins/wasm.tq | 121 +- deps/v8/src/builtins/x64/builtins-x64.cc | 267 +- deps/v8/src/codegen/arm/assembler-arm.cc | 12 +- deps/v8/src/codegen/arm/assembler-arm.h | 15 +- .../v8/src/codegen/arm/macro-assembler-arm.cc | 30 +- deps/v8/src/codegen/arm/macro-assembler-arm.h | 4 + deps/v8/src/codegen/arm/reglist-arm.h | 2 + .../src/codegen/arm64/assembler-arm64-inl.h | 10 + deps/v8/src/codegen/arm64/assembler-arm64.cc | 56 +- deps/v8/src/codegen/arm64/assembler-arm64.h | 26 +- deps/v8/src/codegen/arm64/constants-arm64.h | 16 + deps/v8/src/codegen/arm64/decoder-arm64-inl.h | 7 +- deps/v8/src/codegen/arm64/decoder-arm64.h | 1 + .../src/codegen/arm64/instructions-arm64.cc | 42 + .../v8/src/codegen/arm64/instructions-arm64.h | 17 + .../codegen/arm64/macro-assembler-arm64-inl.h | 50 +- .../codegen/arm64/macro-assembler-arm64.cc | 242 +- .../src/codegen/arm64/macro-assembler-arm64.h | 40 +- deps/v8/src/codegen/arm64/register-arm64.cc | 8 + deps/v8/src/codegen/arm64/register-arm64.h | 67 +- deps/v8/src/codegen/arm64/reglist-arm64.h | 2 + deps/v8/src/codegen/assembler.cc | 22 +- deps/v8/src/codegen/assembler.h | 12 + deps/v8/src/codegen/code-stub-assembler-inl.h | 28 +- deps/v8/src/codegen/code-stub-assembler.cc | 1557 +++++--- deps/v8/src/codegen/code-stub-assembler.h | 315 +- deps/v8/src/codegen/compilation-cache.cc | 20 +- deps/v8/src/codegen/compilation-cache.h | 10 +- deps/v8/src/codegen/compiler.cc | 237 +- deps/v8/src/codegen/compiler.h | 14 +- deps/v8/src/codegen/cpu-features.h | 5 + deps/v8/src/codegen/external-reference.cc | 144 +- deps/v8/src/codegen/external-reference.h | 48 +- .../v8/src/codegen/flush-instruction-cache.cc | 4 +- deps/v8/src/codegen/handler-table.cc | 72 +- deps/v8/src/codegen/handler-table.h | 38 +- deps/v8/src/codegen/ia32/assembler-ia32.cc | 10 +- deps/v8/src/codegen/ia32/assembler-ia32.h | 3 - .../src/codegen/ia32/macro-assembler-ia32.cc | 37 +- .../src/codegen/ia32/macro-assembler-ia32.h | 8 + deps/v8/src/codegen/ia32/reglist-ia32.h | 2 + .../src/codegen/interface-descriptors-inl.h | 38 + deps/v8/src/codegen/interface-descriptors.cc | 2 +- deps/v8/src/codegen/interface-descriptors.h | 111 +- deps/v8/src/codegen/label.h | 9 +- .../src/codegen/loong64/assembler-loong64.cc | 10 +- .../src/codegen/loong64/assembler-loong64.h | 9 +- .../loong64/macro-assembler-loong64.cc | 217 +- .../codegen/loong64/macro-assembler-loong64.h | 48 +- deps/v8/src/codegen/loong64/reglist-loong64.h | 2 + deps/v8/src/codegen/macro-assembler.h | 2 +- deps/v8/src/codegen/maglev-safepoint-table.cc | 34 +- deps/v8/src/codegen/maglev-safepoint-table.h | 38 + .../v8/src/codegen/mips64/assembler-mips64.cc | 10 +- deps/v8/src/codegen/mips64/assembler-mips64.h | 9 +- deps/v8/src/codegen/mips64/constants-mips64.h | 2 +- .../codegen/mips64/macro-assembler-mips64.cc | 53 +- .../codegen/mips64/macro-assembler-mips64.h | 7 + deps/v8/src/codegen/mips64/reglist-mips64.h | 1 + .../src/codegen/optimized-compilation-info.h | 4 + deps/v8/src/codegen/ppc/assembler-ppc.cc | 26 +- deps/v8/src/codegen/ppc/assembler-ppc.h | 32 +- deps/v8/src/codegen/ppc/constants-ppc.h | 34 +- .../v8/src/codegen/ppc/macro-assembler-ppc.cc | 232 +- deps/v8/src/codegen/ppc/macro-assembler-ppc.h | 28 +- deps/v8/src/codegen/ppc/register-ppc.h | 9 - deps/v8/src/codegen/riscv/assembler-riscv.cc | 26 +- deps/v8/src/codegen/riscv/assembler-riscv.h | 26 +- .../src/codegen/riscv/base-assembler-riscv.cc | 2 +- .../src/codegen/riscv/base-constants-riscv.h | 15 - .../v8/src/codegen/riscv/constant-riscv-zfa.h | 70 + deps/v8/src/codegen/riscv/constants-riscv.h | 6 + .../src/codegen/riscv/extension-riscv-zfa.cc | 289 ++ .../src/codegen/riscv/extension-riscv-zfa.h | 112 + .../codegen/riscv/macro-assembler-riscv.cc | 356 +- .../src/codegen/riscv/macro-assembler-riscv.h | 102 +- deps/v8/src/codegen/riscv/register-riscv.h | 35 +- deps/v8/src/codegen/riscv/reglist-riscv.h | 4 +- deps/v8/src/codegen/s390/assembler-s390.cc | 17 +- deps/v8/src/codegen/s390/assembler-s390.h | 9 +- .../src/codegen/s390/macro-assembler-s390.cc | 341 +- .../src/codegen/s390/macro-assembler-s390.h | 39 +- deps/v8/src/codegen/s390/reglist-s390.h | 2 + deps/v8/src/codegen/safepoint-table-base.h | 13 +- deps/v8/src/codegen/safepoint-table.cc | 742 +++- deps/v8/src/codegen/safepoint-table.h | 364 +- deps/v8/src/codegen/source-position-table.cc | 50 +- deps/v8/src/codegen/tnode.h | 10 +- .../turboshaft-builtins-assembler-inl.h | 203 +- deps/v8/src/codegen/x64/assembler-x64-inl.h | 4 +- deps/v8/src/codegen/x64/assembler-x64.cc | 885 +++-- deps/v8/src/codegen/x64/assembler-x64.h | 364 +- .../v8/src/codegen/x64/macro-assembler-x64.cc | 102 +- deps/v8/src/codegen/x64/macro-assembler-x64.h | 22 +- deps/v8/src/codegen/x64/register-x64.h | 2 +- deps/v8/src/codegen/x64/reglist-x64.h | 2 + deps/v8/src/common/assert-scope.h | 3 + deps/v8/src/common/code-memory-access-inl.h | 1 - deps/v8/src/common/globals.h | 269 +- deps/v8/src/common/message-template.h | 9 +- deps/v8/src/common/ptr-compr.h | 7 +- deps/v8/src/common/simd128.h | 2 +- .../lazy-compile-dispatcher.cc | 155 +- .../lazy-compile-dispatcher.h | 28 +- .../optimizing-compile-dispatcher.cc | 27 +- deps/v8/src/compiler/access-builder.cc | 229 +- deps/v8/src/compiler/access-builder.h | 7 +- deps/v8/src/compiler/access-info.cc | 45 +- deps/v8/src/compiler/access-info.h | 3 +- deps/v8/src/compiler/allocation-builder-inl.h | 4 +- .../backend/arm/code-generator-arm.cc | 69 +- .../backend/arm/instruction-selector-arm.cc | 105 +- .../backend/arm64/code-generator-arm64.cc | 412 ++- .../backend/arm64/instruction-codes-arm64.h | 9 +- .../arm64/instruction-scheduler-arm64.cc | 10 +- .../arm64/instruction-selector-arm64.cc | 1631 +++++--- .../v8/src/compiler/backend/block-position.cc | 97 + deps/v8/src/compiler/backend/block-position.h | 41 + .../v8/src/compiler/backend/code-generator.cc | 82 +- deps/v8/src/compiler/backend/code-generator.h | 17 +- .../backend/ia32/code-generator-ia32.cc | 83 +- .../backend/ia32/instruction-selector-ia32.cc | 27 +- .../src/compiler/backend/instruction-codes.h | 97 +- .../compiler/backend/instruction-scheduler.cc | 2 + .../backend/instruction-selector-impl.h | 4 + .../compiler/backend/instruction-selector.cc | 166 +- .../compiler/backend/instruction-selector.h | 51 +- deps/v8/src/compiler/backend/instruction.cc | 6 + deps/v8/src/compiler/backend/instruction.h | 119 +- .../backend/loong64/code-generator-loong64.cc | 377 +- .../loong64/instruction-selector-loong64.cc | 171 +- .../backend/mips64/code-generator-mips64.cc | 96 +- .../mips64/instruction-selector-mips64.cc | 32 +- .../backend/ppc/code-generator-ppc.cc | 326 +- .../backend/ppc/instruction-codes-ppc.h | 15 +- .../backend/ppc/instruction-scheduler-ppc.cc | 15 +- .../backend/ppc/instruction-selector-ppc.cc | 161 +- .../compiler/backend/register-allocator.cc | 1 - .../backend/riscv/code-generator-riscv.cc | 282 +- .../backend/riscv/instruction-codes-riscv.h | 13 +- .../riscv/instruction-scheduler-riscv.cc | 72 +- .../riscv/instruction-selector-riscv.h | 86 +- .../riscv/instruction-selector-riscv32.cc | 130 +- .../riscv/instruction-selector-riscv64.cc | 330 +- .../riscv/register-constraints-riscv.h | 10 +- .../backend/s390/code-generator-s390.cc | 210 +- .../backend/s390/instruction-selector-s390.cc | 80 +- .../backend/x64/code-generator-x64.cc | 812 ++-- .../backend/x64/instruction-codes-x64.h | 5 +- .../backend/x64/instruction-scheduler-x64.cc | 9 +- .../backend/x64/instruction-selector-x64.cc | 710 ++-- .../basic-block-call-graph-profiler.cc | 4 +- deps/v8/src/compiler/bytecode-analysis.cc | 5 +- .../v8/src/compiler/bytecode-graph-builder.cc | 129 +- deps/v8/src/compiler/c-linkage.cc | 2 +- deps/v8/src/compiler/code-assembler.cc | 8 +- deps/v8/src/compiler/code-assembler.h | 85 +- .../src/compiler/compilation-dependencies.cc | 8 +- .../src/compiler/compilation-dependencies.h | 1 + deps/v8/src/compiler/fast-api-calls.cc | 10 +- deps/v8/src/compiler/frame-states.cc | 19 +- deps/v8/src/compiler/frame-states.h | 4 + deps/v8/src/compiler/globals.h | 2 +- deps/v8/src/compiler/graph-assembler.cc | 35 +- deps/v8/src/compiler/graph-assembler.h | 6 +- deps/v8/src/compiler/heap-refs.cc | 376 +- deps/v8/src/compiler/heap-refs.h | 86 +- deps/v8/src/compiler/int64-lowering.cc | 2 +- deps/v8/src/compiler/js-call-reducer.cc | 726 +++- deps/v8/src/compiler/js-call-reducer.h | 6 +- deps/v8/src/compiler/js-create-lowering.cc | 45 +- deps/v8/src/compiler/js-generic-lowering.cc | 4 + deps/v8/src/compiler/js-heap-broker.cc | 84 +- deps/v8/src/compiler/js-heap-broker.h | 4 +- deps/v8/src/compiler/js-inlining-heuristic.cc | 51 +- deps/v8/src/compiler/js-inlining.cc | 2 +- deps/v8/src/compiler/js-intrinsic-lowering.cc | 4 +- .../js-native-context-specialization.cc | 192 +- .../js-native-context-specialization.h | 4 + deps/v8/src/compiler/js-operator.cc | 15 +- deps/v8/src/compiler/js-operator.h | 18 +- deps/v8/src/compiler/js-typed-lowering.cc | 263 +- deps/v8/src/compiler/js-typed-lowering.h | 2 + deps/v8/src/compiler/linkage.h | 12 +- deps/v8/src/compiler/load-elimination.cc | 2 +- .../src/compiler/loop-variable-optimizer.cc | 3 +- .../v8/src/compiler/machine-graph-verifier.cc | 6 +- .../src/compiler/machine-operator-reducer.cc | 13 +- deps/v8/src/compiler/machine-operator.cc | 127 +- deps/v8/src/compiler/machine-operator.h | 4 +- deps/v8/src/compiler/memory-optimizer.cc | 32 +- deps/v8/src/compiler/memory-optimizer.h | 6 +- deps/v8/src/compiler/node-matchers.h | 4 +- deps/v8/src/compiler/node-properties.cc | 5 +- deps/v8/src/compiler/opcodes.h | 27 +- deps/v8/src/compiler/operation-typer.cc | 14 +- deps/v8/src/compiler/operator-properties.cc | 2 + .../src/compiler/pair-load-store-reducer.cc | 94 - .../v8/src/compiler/pair-load-store-reducer.h | 46 - deps/v8/src/compiler/pipeline-data-inl.h | 2 +- deps/v8/src/compiler/pipeline-statistics.cc | 18 +- deps/v8/src/compiler/pipeline.cc | 219 +- deps/v8/src/compiler/pipeline.h | 13 +- deps/v8/src/compiler/processed-feedback.h | 21 + deps/v8/src/compiler/representation-change.cc | 56 +- deps/v8/src/compiler/revectorizer.cc | 38 +- .../compiler/simplified-lowering-verifier.cc | 10 +- deps/v8/src/compiler/simplified-lowering.cc | 186 +- .../compiler/simplified-operator-reducer.cc | 46 + deps/v8/src/compiler/simplified-operator.cc | 109 + deps/v8/src/compiler/simplified-operator.h | 49 + .../src/compiler/string-builder-optimizer.cc | 1209 ------ .../src/compiler/string-builder-optimizer.h | 378 -- deps/v8/src/compiler/turbofan-disabled.cc | 3 +- .../src/compiler/turbofan-graph-visualizer.cc | 28 +- deps/v8/src/compiler/turbofan-typer.cc | 13 +- deps/v8/src/compiler/turbofan-types.cc | 5 + .../src/compiler/turboshaft/access-builder.h | 8 +- deps/v8/src/compiler/turboshaft/assembler.h | 337 +- .../turboshaft/builtin-call-descriptors.h | 116 +- ...de-elimination-and-simplification-phase.cc | 8 +- .../src/compiler/turboshaft/copying-phase.h | 25 +- .../turboshaft/csa-effects-computation.cc | 3 +- .../turboshaft/decompression-optimization.cc | 2 +- .../turboshaft/define-assembler-macros.inc | 11 +- .../duplication-optimization-reducer.h | 23 +- .../fast-api-call-lowering-reducer.h | 75 +- .../src/compiler/turboshaft/graph-builder.cc | 127 +- deps/v8/src/compiler/turboshaft/graph.cc | 9 + deps/v8/src/compiler/turboshaft/graph.h | 28 + deps/v8/src/compiler/turboshaft/index.h | 22 +- ...truction-selection-normalization-reducer.h | 2 +- .../turboshaft/instruction-selection-phase.cc | 38 + .../turboshaft/int64-lowering-reducer.h | 146 +- .../late-escape-analysis-reducer.cc | 2 +- .../late-load-elimination-reducer.cc | 41 +- .../late-load-elimination-reducer.h | 21 +- ...ion-phase.cc => load-elimination-phase.cc} | 13 +- ...imize-phase.h => load-elimination-phase.h} | 10 +- .../load-store-simplification-reducer.h | 13 +- .../load-store-verification-reducer.h | 14 +- .../turboshaft/loop-unrolling-reducer.cc | 33 +- .../turboshaft/loop-unrolling-reducer.h | 1 + .../turboshaft/machine-lowering-reducer-inl.h | 252 +- .../turboshaft/machine-optimization-reducer.h | 268 +- .../turboshaft/maglev-assert-types-reducer.h | 7 +- ...-phase.cc => memory-optimization-phase.cc} | 4 +- ...on-phase.h => memory-optimization-phase.h} | 10 +- .../turboshaft/memory-optimization-reducer.h | 16 +- .../compiler/turboshaft/operation-matcher.h | 20 + deps/v8/src/compiler/turboshaft/operations.cc | 64 +- deps/v8/src/compiler/turboshaft/operations.h | 558 ++- deps/v8/src/compiler/turboshaft/opmasks.h | 5 + deps/v8/src/compiler/turboshaft/phase.cc | 3 +- deps/v8/src/compiler/turboshaft/phase.h | 39 +- deps/v8/src/compiler/turboshaft/pipelines.cc | 9 +- deps/v8/src/compiler/turboshaft/pipelines.h | 24 +- .../turboshaft/register-allocation-phase.h | 18 + .../required-optimization-reducer.h | 2 +- deps/v8/src/compiler/turboshaft/sidetable.h | 2 + .../store-store-elimination-reducer-inl.h | 63 +- deps/v8/src/compiler/turboshaft/string-view.h | 4 +- .../turbolev-early-lowering-reducer-inl.h | 15 +- .../turboshaft/turbolev-frontend-pipeline.cc | 10 +- .../turboshaft/turbolev-graph-builder.cc | 292 +- .../turboshaft/type-inference-analysis.h | 1 + deps/v8/src/compiler/turboshaft/typer.h | 25 +- deps/v8/src/compiler/turboshaft/typeswitch.h | 60 +- .../turboshaft/undef-assembler-macros.inc | 6 +- deps/v8/src/compiler/turboshaft/use-map.cc | 5 +- .../turboshaft/value-numbering-reducer.h | 55 +- .../turboshaft/wasm-assembler-helpers.h | 13 + .../wasm-gc-typed-optimization-reducer.cc | 35 + .../wasm-gc-typed-optimization-reducer.h | 74 +- .../wasm-in-js-inlining-reducer-inl.h | 1390 +++---- .../turboshaft/wasm-js-lowering-reducer.h | 32 +- .../wasm-load-elimination-reducer.h | 81 +- .../turboshaft/wasm-lowering-reducer.h | 321 +- .../compiler/turboshaft/wasm-revec-reducer.cc | 59 +- .../compiler/turboshaft/wasm-revec-reducer.h | 25 +- .../turboshaft/wasm-shuffle-reducer.cc | 527 +-- .../turboshaft/wasm-shuffle-reducer.h | 449 ++- .../turboshaft/wasm-turboshaft-compiler.cc | 7 - .../turboshaft/wasm-wrappers-inl.h} | 498 ++- .../src/compiler/turboshaft/wasm-wrappers.cc | 69 + .../turboshaft/wasm-wrappers.h} | 360 +- deps/v8/src/compiler/type-cache.h | 16 +- deps/v8/src/compiler/use-info.h | 9 + deps/v8/src/compiler/verifier.cc | 18 +- .../compiler/wasm-address-reassociation.cc | 20 +- .../src/compiler/wasm-address-reassociation.h | 2 +- .../src/compiler/wasm-compiler-definitions.cc | 20 +- .../src/compiler/wasm-compiler-definitions.h | 11 +- deps/v8/src/compiler/wasm-compiler.cc | 566 +-- deps/v8/src/compiler/wasm-compiler.h | 64 +- deps/v8/src/compiler/wasm-gc-lowering.cc | 42 +- deps/v8/src/compiler/wasm-graph-assembler.cc | 109 +- deps/v8/src/compiler/wasm-graph-assembler.h | 6 +- deps/v8/src/compiler/wasm-inlining-into-js.cc | 9 +- deps/v8/src/compiler/wasm-load-elimination.cc | 5 +- deps/v8/src/compiler/wasm-typer.cc | 1 - deps/v8/src/d8/OWNERS | 1 + deps/v8/src/d8/async-hooks-wrapper.cc | 6 +- deps/v8/src/d8/d8-console.cc | 32 +- deps/v8/src/d8/d8-posix.cc | 67 +- deps/v8/src/d8/d8-windows.cc | 76 +- deps/v8/src/d8/d8.cc | 818 ++-- deps/v8/src/d8/d8.h | 40 +- deps/v8/src/d8/hardware-watchpoints.cc | 430 ++- deps/v8/src/date/date.cc | 2 +- deps/v8/src/date/date.h | 8 +- deps/v8/src/date/dateparser-inl.h | 5 +- deps/v8/src/debug/DIR_METADATA | 7 +- deps/v8/src/debug/debug-coverage.cc | 6 +- deps/v8/src/debug/debug-evaluate.cc | 7 +- deps/v8/src/debug/debug-interface.cc | 90 +- deps/v8/src/debug/debug-interface.h | 16 +- deps/v8/src/debug/debug-property-iterator.cc | 11 +- deps/v8/src/debug/debug-scopes.cc | 75 +- .../src/debug/debug-stack-trace-iterator.cc | 2 + deps/v8/src/debug/debug-wasm-objects-inl.h | 2 - deps/v8/src/debug/debug-wasm-objects.cc | 52 +- deps/v8/src/debug/debug-wasm-objects.h | 7 +- deps/v8/src/debug/debug.cc | 119 +- deps/v8/src/debug/debug.h | 6 +- deps/v8/src/debug/liveedit.cc | 42 +- .../src/debug/wasm/gdb-server/gdb-server.cc | 2 +- deps/v8/src/debug/wasm/gdb-server/target.cc | 2 + .../wasm/gdb-server/wasm-module-debug.cc | 10 +- .../src/deoptimizer/deoptimized-frame-info.h | 4 +- deps/v8/src/deoptimizer/deoptimizer.cc | 143 +- .../deoptimizer/frame-translation-builder.cc | 15 +- .../deoptimizer/frame-translation-builder.h | 8 +- .../loong64/deoptimizer-loong64.cc | 2 + .../deoptimizer/materialized-object-store.cc | 50 +- .../deoptimizer/materialized-object-store.h | 6 +- .../deoptimizer/mips64/deoptimizer-mips64.cc | 2 + deps/v8/src/deoptimizer/translated-state.cc | 291 +- deps/v8/src/deoptimizer/translated-state.h | 52 +- deps/v8/src/diagnostics/arm64/disasm-arm64.cc | 56 +- deps/v8/src/diagnostics/arm64/disasm-arm64.h | 1 + .../src/diagnostics/basic-block-profiler.cc | 70 +- deps/v8/src/diagnostics/code-tracer.h | 2 +- deps/v8/src/diagnostics/disasm.h | 8 +- deps/v8/src/diagnostics/disassembler.cc | 4 +- deps/v8/src/diagnostics/disassembler.h | 2 +- deps/v8/src/diagnostics/gdb-jit.cc | 66 +- deps/v8/src/diagnostics/gdb-jit.h | 7 + deps/v8/src/diagnostics/objects-debug.cc | 1626 ++++++-- deps/v8/src/diagnostics/objects-printer.cc | 1120 ++++-- deps/v8/src/diagnostics/perf-jit.cc | 15 +- deps/v8/src/diagnostics/ppc/disasm-ppc.cc | 15 + deps/v8/src/diagnostics/riscv/disasm-riscv.cc | 95 +- deps/v8/src/diagnostics/x64/disasm-x64.cc | 572 ++- deps/v8/src/dumpling/dumpling-manager.cc | 39 +- deps/v8/src/dumpling/dumpling-manager.h | 42 +- deps/v8/src/dumpling/object-dumping.cc | 457 +-- deps/v8/src/dumpling/object-dumping.h | 8 +- deps/v8/src/execution/arguments.h | 17 +- .../src/execution/arm/frame-constants-arm.h | 1 + .../execution/arm64/frame-constants-arm64.h | 5 + .../v8/src/execution/arm64/simulator-arm64.cc | 42 +- deps/v8/src/execution/arm64/simulator-arm64.h | 24 +- .../execution/arm64/simulator-logic-arm64.cc | 54 + deps/v8/src/execution/execution.cc | 65 +- deps/v8/src/execution/frame-constants.h | 34 +- deps/v8/src/execution/frames-inl.h | 91 +- deps/v8/src/execution/frames.cc | 632 ++-- deps/v8/src/execution/frames.h | 41 +- deps/v8/src/execution/futex-emulation.cc | 282 +- deps/v8/src/execution/futex-emulation.h | 92 +- .../src/execution/ia32/frame-constants-ia32.h | 1 + deps/v8/src/execution/isolate-data-fields.h | 3 + deps/v8/src/execution/isolate-data.h | 13 + deps/v8/src/execution/isolate-inl.h | 9 +- deps/v8/src/execution/isolate.cc | 810 ++-- deps/v8/src/execution/isolate.h | 109 +- deps/v8/src/execution/local-isolate-inl.h | 10 +- deps/v8/src/execution/local-isolate.cc | 30 +- deps/v8/src/execution/local-isolate.h | 2 + .../loong64/frame-constants-loong64.h | 5 + .../execution/loong64/simulator-loong64.cc | 205 +- .../src/execution/loong64/simulator-loong64.h | 4 +- deps/v8/src/execution/messages.cc | 73 +- deps/v8/src/execution/messages.h | 4 +- deps/v8/src/execution/microtask-queue.cc | 5 +- .../execution/mips64/frame-constants-mips64.h | 5 + .../src/execution/mips64/simulator-mips64.cc | 1 - .../src/execution/ppc/frame-constants-ppc.h | 8 +- deps/v8/src/execution/ppc/simulator-ppc.cc | 23 +- deps/v8/src/execution/protectors.cc | 8 +- deps/v8/src/execution/protectors.h | 2 + .../execution/riscv/frame-constants-riscv.h | 13 +- .../v8/src/execution/riscv/simulator-riscv.cc | 358 +- deps/v8/src/execution/riscv/simulator-riscv.h | 16 +- .../src/execution/s390/frame-constants-s390.h | 1 + deps/v8/src/execution/s390/simulator-s390.cc | 6 - deps/v8/src/execution/simulator.h | 5 +- deps/v8/src/execution/stack-guard.cc | 32 +- deps/v8/src/execution/thread-local-top.cc | 4 +- deps/v8/src/execution/tiering-manager.cc | 4 +- deps/v8/src/execution/v8threads.cc | 2 +- deps/v8/src/execution/vm-state-inl.h | 7 +- .../src/execution/x64/frame-constants-x64.h | 1 + .../externalize-string-extension.cc | 19 +- deps/v8/src/extensions/gc-extension.cc | 15 +- .../ignition-statistics-extension.cc | 40 - .../ignition-statistics-extension.h | 35 - .../v8/src/extensions/statistics-extension.cc | 14 +- deps/v8/src/flags/flag-definitions.h | 906 +++-- deps/v8/src/flags/flags.cc | 88 +- deps/v8/src/flags/flags.h | 18 + deps/v8/src/fuzzilli/cov.cc | 122 +- deps/v8/src/fuzzilli/cov.h | 1 + deps/v8/src/fuzzilli/fuzzilli.cc | 2 + deps/v8/src/handles/global-handles.cc | 2 +- deps/v8/src/handles/handles-inl.h | 1 + deps/v8/src/handles/maybe-handles-inl.h | 71 +- deps/v8/src/handles/maybe-handles.h | 12 +- deps/v8/src/handles/traced-handles.cc | 50 +- deps/v8/src/handles/traced-handles.h | 16 +- deps/v8/src/heap/WRITE_BARRIER.md | 22 +- deps/v8/src/heap/base-space.h | 6 - deps/v8/src/heap/base/bytes.h | 30 +- deps/v8/src/heap/base/memory-tagging.cc | 2 +- deps/v8/src/heap/base/stack.h | 8 +- deps/v8/src/heap/code-range.cc | 44 +- deps/v8/src/heap/code-stats.cc | 2 +- deps/v8/src/heap/collection-barrier.cc | 7 +- .../src/heap/conservative-stack-visitor-inl.h | 7 +- deps/v8/src/heap/cppgc-js/cpp-heap.cc | 19 +- deps/v8/src/heap/cppgc-js/cpp-heap.h | 3 +- deps/v8/src/heap/cppgc-js/cpp-snapshot.cc | 111 +- deps/v8/src/heap/cppgc-js/cpp-snapshot.h | 5 +- deps/v8/src/heap/cppgc/caged-heap.cc | 26 +- deps/v8/src/heap/cppgc/heap-base.cc | 14 +- deps/v8/src/heap/cppgc/heap-base.h | 7 +- deps/v8/src/heap/cppgc/heap-page.cc | 24 +- deps/v8/src/heap/cppgc/heap-page.h | 24 +- deps/v8/src/heap/cppgc/heap.cc | 3 +- deps/v8/src/heap/cppgc/logging.cc | 11 +- deps/v8/src/heap/cppgc/object-start-bitmap.h | 8 +- deps/v8/src/heap/cppgc/page-memory.cc | 61 +- deps/v8/src/heap/cppgc/page-memory.h | 13 +- deps/v8/src/heap/cppgc/platform.cc | 13 +- deps/v8/src/heap/cppgc/stats-collector.h | 30 +- deps/v8/src/heap/cppgc/sweeper.cc | 2 +- deps/v8/src/heap/evacuation-allocator-inl.h | 21 +- deps/v8/src/heap/factory-base-inl.h | 13 +- deps/v8/src/heap/factory-base.cc | 116 +- deps/v8/src/heap/factory-base.h | 81 +- deps/v8/src/heap/factory-inl.h | 9 +- deps/v8/src/heap/factory.cc | 1164 ++++-- deps/v8/src/heap/factory.h | 240 +- deps/v8/src/heap/gc-tracer.cc | 43 +- deps/v8/src/heap/gc-tracer.h | 22 +- deps/v8/src/heap/heap-allocator-inl.h | 21 +- deps/v8/src/heap/heap-allocator.cc | 47 +- deps/v8/src/heap/heap-allocator.h | 15 +- deps/v8/src/heap/heap-controller.cc | 138 +- deps/v8/src/heap/heap-controller.h | 40 +- deps/v8/src/heap/heap-inl.h | 11 +- deps/v8/src/heap/heap-verifier.cc | 35 +- deps/v8/src/heap/heap-visitor-inl.h | 2 - deps/v8/src/heap/heap-visitor.cc | 2 +- deps/v8/src/heap/heap-visitor.h | 27 +- deps/v8/src/heap/heap-write-barrier-inl.h | 43 + deps/v8/src/heap/heap-write-barrier.h | 10 + deps/v8/src/heap/heap.cc | 554 ++- deps/v8/src/heap/heap.h | 75 +- deps/v8/src/heap/incremental-marking.cc | 67 +- deps/v8/src/heap/local-heap-inl.h | 18 +- deps/v8/src/heap/main-allocator-inl.h | 28 +- deps/v8/src/heap/main-allocator.cc | 57 +- deps/v8/src/heap/main-allocator.h | 28 +- deps/v8/src/heap/mark-compact.cc | 460 ++- deps/v8/src/heap/mark-compact.h | 32 +- deps/v8/src/heap/marking-inl.h | 9 +- deps/v8/src/heap/marking-state-inl.h | 2 +- deps/v8/src/heap/marking-visitor-inl.h | 46 +- deps/v8/src/heap/marking-visitor.h | 2 + deps/v8/src/heap/memory-allocator.cc | 12 + deps/v8/src/heap/memory-chunk-inl.h | 2 +- deps/v8/src/heap/memory-chunk.cc | 13 +- deps/v8/src/heap/memory-chunk.h | 2 +- deps/v8/src/heap/memory-measurement.cc | 20 +- deps/v8/src/heap/minor-gc-job.cc | 4 +- deps/v8/src/heap/minor-mark-sweep-inl.h | 8 +- deps/v8/src/heap/minor-mark-sweep.cc | 17 - deps/v8/src/heap/mutable-page-inl.h | 1 - deps/v8/src/heap/new-spaces.h | 9 - deps/v8/src/heap/object-stats.cc | 35 +- deps/v8/src/heap/paged-spaces-inl.h | 21 +- deps/v8/src/heap/pretenuring-handler.cc | 59 +- deps/v8/src/heap/read-only-heap-inl.h | 3 +- deps/v8/src/heap/read-only-heap.cc | 20 + deps/v8/src/heap/read-only-heap.h | 4 + deps/v8/src/heap/read-only-promotion.cc | 26 +- deps/v8/src/heap/read-only-spaces.cc | 2 +- deps/v8/src/heap/read-only-spaces.h | 2 +- deps/v8/src/heap/remembered-set.h | 4 +- deps/v8/src/heap/safepoint.cc | 40 +- deps/v8/src/heap/safepoint.h | 4 - deps/v8/src/heap/scavenger.cc | 9 +- deps/v8/src/heap/setup-heap-internal.cc | 180 +- deps/v8/src/heap/spaces-inl.h | 3 +- .../heap/traced-handles-marking-visitor.cc | 16 +- .../src/heap/traced-handles-marking-visitor.h | 2 +- deps/v8/src/heap/weak-object-worklists.h | 2 +- deps/v8/src/ic/accessor-assembler.cc | 577 +-- deps/v8/src/ic/accessor-assembler.h | 29 +- deps/v8/src/ic/binary-op-assembler.cc | 2 +- deps/v8/src/ic/handler-configuration-inl.h | 102 +- deps/v8/src/ic/handler-configuration.cc | 55 +- deps/v8/src/ic/handler-configuration.h | 101 +- deps/v8/src/ic/ic.cc | 144 +- deps/v8/src/ic/ic.h | 4 +- deps/v8/src/ic/keyed-store-generic.cc | 12 +- deps/v8/src/ic/stub-cache.h | 4 +- deps/v8/src/init/bootstrapper.cc | 477 ++- deps/v8/src/init/bootstrapper.h | 5 + deps/v8/src/init/heap-symbols.h | 1 - deps/v8/src/init/icu_util.cc | 5 + deps/v8/src/init/icu_util.h | 8 +- deps/v8/src/init/isolate-group.cc | 46 + deps/v8/src/init/isolate-group.h | 4 + deps/v8/src/init/v8.cc | 3 +- deps/v8/src/inspector/DIR_METADATA | 7 +- deps/v8/src/inspector/SECURITY.md | 34 + deps/v8/src/inspector/custom-preview.cc | 2 +- deps/v8/src/inspector/injected-script.cc | 13 +- deps/v8/src/inspector/injected-script.h | 10 + deps/v8/src/inspector/string-util.h | 5 + deps/v8/src/inspector/v8-console-message.cc | 13 +- deps/v8/src/inspector/v8-console.cc | 114 +- deps/v8/src/inspector/v8-console.h | 6 +- .../src/inspector/v8-debugger-agent-impl.cc | 318 +- .../v8/src/inspector/v8-debugger-agent-impl.h | 13 +- deps/v8/src/inspector/v8-debugger-script.cc | 18 +- deps/v8/src/inspector/v8-debugger-script.h | 11 +- deps/v8/src/inspector/v8-debugger.cc | 30 +- deps/v8/src/inspector/v8-deep-serializer.cc | 1 + .../inspector/v8-heap-profiler-agent-impl.cc | 5 +- deps/v8/src/inspector/v8-inspector-impl.cc | 35 +- deps/v8/src/inspector/v8-inspector-impl.h | 10 +- .../inspector/v8-inspector-session-impl.cc | 23 +- .../src/inspector/v8-inspector-session-impl.h | 12 +- .../src/inspector/v8-profiler-agent-impl.cc | 12 +- .../v8/src/inspector/v8-runtime-agent-impl.cc | 37 +- deps/v8/src/inspector/v8-stack-trace-impl.cc | 6 +- deps/v8/src/inspector/value-mirror.cc | 68 +- .../src/interpreter/bytecode-array-builder.cc | 51 +- .../src/interpreter/bytecode-array-builder.h | 37 +- .../interpreter/bytecode-array-iterator.cc | 13 +- .../src/interpreter/bytecode-array-iterator.h | 6 +- deps/v8/src/interpreter/bytecode-decoder.cc | 11 +- deps/v8/src/interpreter/bytecode-decoder.h | 2 +- deps/v8/src/interpreter/bytecode-generator.cc | 232 +- deps/v8/src/interpreter/bytecode-generator.h | 32 +- deps/v8/src/interpreter/bytecode-operands.h | 2 +- deps/v8/src/interpreter/bytecodes.h | 13 +- .../src/interpreter/constant-array-builder.cc | 14 +- .../src/interpreter/control-flow-builders.cc | 27 +- .../src/interpreter/control-flow-builders.h | 2 +- .../src/interpreter/handler-table-builder.cc | 32 +- .../src/interpreter/handler-table-builder.h | 2 + .../src/interpreter/interpreter-assembler.cc | 65 +- .../src/interpreter/interpreter-assembler.h | 3 - .../interpreter/interpreter-generator-tsa.cc | 4 - .../src/interpreter/interpreter-generator.cc | 89 +- .../interpreter-intrinsics-generator.cc | 4 +- deps/v8/src/interpreter/interpreter.cc | 72 +- deps/v8/src/interpreter/interpreter.h | 17 - .../prototype-assignment-sequence-builder.cc | 7 +- deps/v8/src/json/json-parser.cc | 753 +--- deps/v8/src/json/json-parser.h | 9 + deps/v8/src/json/json-stringifier.cc | 60 +- deps/v8/src/libsampler/sampler.cc | 3 + deps/v8/src/logging/code-events.h | 9 +- deps/v8/src/logging/counters-definitions.h | 24 +- deps/v8/src/logging/log-file.cc | 2 - deps/v8/src/logging/log.cc | 117 +- deps/v8/src/logging/log.h | 12 +- deps/v8/src/logging/runtime-call-stats.h | 5 +- .../src/maglev/arm/maglev-assembler-arm-inl.h | 35 + deps/v8/src/maglev/arm/maglev-ir-arm.cc | 41 +- .../maglev/arm64/maglev-assembler-arm64-inl.h | 37 + deps/v8/src/maglev/arm64/maglev-ir-arm64.cc | 44 +- .../loong64/maglev-assembler-loong64-inl.h | 36 + .../src/maglev/loong64/maglev-ir-loong64.cc | 61 +- deps/v8/src/maglev/maglev-assembler.cc | 59 +- deps/v8/src/maglev/maglev-assembler.h | 12 +- deps/v8/src/maglev/maglev-code-generator.cc | 119 +- deps/v8/src/maglev/maglev-code-generator.h | 5 + deps/v8/src/maglev/maglev-compilation-info.cc | 13 +- deps/v8/src/maglev/maglev-compilation-info.h | 17 +- deps/v8/src/maglev/maglev-compiler.cc | 50 +- .../maglev/maglev-concurrent-dispatcher.cc | 34 +- deps/v8/src/maglev/maglev-graph-builder.cc | 3274 ++++++++++------- deps/v8/src/maglev/maglev-graph-builder.h | 229 +- deps/v8/src/maglev/maglev-graph-labeller.h | 11 +- deps/v8/src/maglev/maglev-graph-optimizer.cc | 278 +- deps/v8/src/maglev/maglev-graph-optimizer.h | 8 +- deps/v8/src/maglev/maglev-graph-printer.cc | 84 +- deps/v8/src/maglev/maglev-graph-printer.h | 6 + deps/v8/src/maglev/maglev-graph.cc | 72 +- deps/v8/src/maglev/maglev-graph.h | 24 +- deps/v8/src/maglev/maglev-inlining.cc | 159 +- deps/v8/src/maglev/maglev-inlining.h | 6 +- .../maglev/maglev-interpreter-frame-state.cc | 231 +- .../maglev/maglev-interpreter-frame-state.h | 74 +- deps/v8/src/maglev/maglev-ir-inl.h | 2 +- deps/v8/src/maglev/maglev-ir.cc | 441 ++- deps/v8/src/maglev/maglev-ir.h | 491 ++- deps/v8/src/maglev/maglev-kna-processor.h | 39 +- .../src/maglev/maglev-known-node-aspects.cc | 287 +- .../v8/src/maglev/maglev-known-node-aspects.h | 244 +- deps/v8/src/maglev/maglev-map-inference.h | 121 + deps/v8/src/maglev/maglev-node-type.h | 6 + .../maglev-phi-representation-selector.cc | 167 +- .../maglev-phi-representation-selector.h | 15 +- .../src/maglev/maglev-pipeline-statistics.cc | 18 +- ...maglev-post-hoc-optimizations-processors.h | 36 +- deps/v8/src/maglev/maglev-range-analysis.h | 20 + deps/v8/src/maglev/maglev-range.h | 2 +- deps/v8/src/maglev/maglev-reducer-inl.h | 753 +++- deps/v8/src/maglev/maglev-reducer.h | 138 +- .../v8/src/maglev/maglev-regalloc-node-info.h | 23 +- deps/v8/src/maglev/maglev-regalloc.cc | 7 - deps/v8/src/maglev/maglev-tracer.h | 226 ++ deps/v8/src/maglev/maglev-truncation.h | 18 +- .../src/maglev/ppc/maglev-assembler-ppc-inl.h | 43 + deps/v8/src/maglev/ppc/maglev-ir-ppc.cc | 44 +- .../maglev/riscv/maglev-assembler-riscv-inl.h | 77 +- .../maglev/riscv/maglev-assembler-riscv.cc | 6 + deps/v8/src/maglev/riscv/maglev-ir-riscv.cc | 62 +- .../maglev/s390/maglev-assembler-s390-inl.h | 51 +- deps/v8/src/maglev/s390/maglev-ir-s390.cc | 59 +- .../src/maglev/x64/maglev-assembler-x64-inl.h | 61 + deps/v8/src/maglev/x64/maglev-ir-x64.cc | 25 +- deps/v8/src/numbers/conversions-inl.h | 4 +- deps/v8/src/numbers/conversions.cc | 37 +- deps/v8/src/numbers/conversions.h | 4 +- deps/v8/src/objects/abstract-code-inl.h | 12 +- deps/v8/src/objects/abstract-code.h | 1 + deps/v8/src/objects/all-objects-inl.h | 6 +- deps/v8/src/objects/allocation-site.h | 2 +- deps/v8/src/objects/api-callbacks-inl.h | 42 +- deps/v8/src/objects/api-callbacks.h | 171 +- deps/v8/src/objects/api-callbacks.tq | 7 +- deps/v8/src/objects/arguments-inl.h | 15 +- deps/v8/src/objects/arguments.h | 67 +- deps/v8/src/objects/arguments.tq | 22 +- deps/v8/src/objects/backing-store.cc | 57 +- deps/v8/src/objects/backing-store.h | 4 +- deps/v8/src/objects/bigint.cc | 281 +- deps/v8/src/objects/bigint.h | 47 +- deps/v8/src/objects/bigint.tq | 5 +- deps/v8/src/objects/bytecode-array-inl.h | 179 +- deps/v8/src/objects/bytecode-array.cc | 30 +- deps/v8/src/objects/bytecode-array.h | 117 +- deps/v8/src/objects/bytecode-array.tq | 6 +- deps/v8/src/objects/call-site-info-inl.h | 17 +- deps/v8/src/objects/call-site-info.cc | 72 +- deps/v8/src/objects/call-site-info.h | 30 +- deps/v8/src/objects/call-site-info.tq | 6 +- deps/v8/src/objects/casting.h | 42 +- deps/v8/src/objects/cell-inl.h | 32 +- deps/v8/src/objects/cell.h | 34 +- deps/v8/src/objects/cell.tq | 1 + deps/v8/src/objects/code-inl.h | 45 +- deps/v8/src/objects/code-kind.h | 6 +- deps/v8/src/objects/code.cc | 21 +- deps/v8/src/objects/code.h | 35 +- .../src/objects/compilation-cache-table-inl.h | 6 +- .../v8/src/objects/compilation-cache-table.cc | 46 +- deps/v8/src/objects/compressed-slots.h | 2 +- deps/v8/src/objects/contexts-inl.h | 81 +- deps/v8/src/objects/contexts.cc | 35 +- deps/v8/src/objects/contexts.h | 165 +- deps/v8/src/objects/contexts.tq | 10 +- .../objects/cpp-heap-external-object-inl.h | 23 - .../v8/src/objects/cpp-heap-external-object.h | 19 +- .../src/objects/cpp-heap-external-object.tq | 1 + deps/v8/src/objects/data-handler.h | 10 +- deps/v8/src/objects/data-handler.tq | 8 +- deps/v8/src/objects/debug-objects-inl.h | 249 +- deps/v8/src/objects/debug-objects.cc | 97 +- deps/v8/src/objects/debug-objects.h | 240 +- deps/v8/src/objects/debug-objects.tq | 15 +- deps/v8/src/objects/deoptimization-data-inl.h | 16 +- deps/v8/src/objects/deoptimization-data.cc | 26 +- deps/v8/src/objects/deoptimization-data.h | 2 +- deps/v8/src/objects/dependent-code-inl.h | 2 - deps/v8/src/objects/dependent-code.cc | 5 +- deps/v8/src/objects/dependent-code.h | 2 - deps/v8/src/objects/descriptor-array-inl.h | 157 +- deps/v8/src/objects/descriptor-array.h | 190 +- deps/v8/src/objects/descriptor-array.tq | 7 +- deps/v8/src/objects/dictionary-inl.h | 11 +- deps/v8/src/objects/elements-kind.cc | 10 +- deps/v8/src/objects/elements-kind.h | 8 + deps/v8/src/objects/elements.cc | 328 +- deps/v8/src/objects/elements.h | 5 +- deps/v8/src/objects/embedder-data-array-inl.h | 11 +- deps/v8/src/objects/embedder-data-array.cc | 2 +- deps/v8/src/objects/embedder-data-array.h | 50 +- deps/v8/src/objects/embedder-data-array.tq | 1 + deps/v8/src/objects/embedder-data-slot-inl.h | 7 +- deps/v8/src/objects/feedback-cell-inl.h | 62 +- deps/v8/src/objects/feedback-cell.h | 35 +- deps/v8/src/objects/feedback-cell.tq | 1 + .../src/objects/feedback-transition-table.cc | 29 + deps/v8/src/objects/feedback-vector-inl.h | 121 +- deps/v8/src/objects/feedback-vector.cc | 106 +- deps/v8/src/objects/feedback-vector.h | 194 +- deps/v8/src/objects/feedback-vector.tq | 12 +- deps/v8/src/objects/field-index-inl.h | 55 +- deps/v8/src/objects/field-index.h | 56 +- deps/v8/src/objects/fixed-array-inl.h | 368 +- deps/v8/src/objects/fixed-array.cc | 133 +- deps/v8/src/objects/fixed-array.h | 373 +- deps/v8/src/objects/fixed-array.tq | 58 +- deps/v8/src/objects/foreign-inl.h | 36 +- deps/v8/src/objects/foreign.h | 49 +- deps/v8/src/objects/foreign.tq | 2 + deps/v8/src/objects/hash-table-inl.h | 4 +- deps/v8/src/objects/heap-number-inl.h | 12 +- deps/v8/src/objects/heap-number.h | 3 + deps/v8/src/objects/heap-object.h | 151 +- deps/v8/src/objects/hole.tq | 10 +- deps/v8/src/objects/instance-type-inl.h | 8 - deps/v8/src/objects/instance-type.h | 71 +- deps/v8/src/objects/instruction-stream-inl.h | 17 +- deps/v8/src/objects/instruction-stream.h | 9 +- deps/v8/src/objects/internal-index.h | 5 + deps/v8/src/objects/intl-objects.cc | 121 +- deps/v8/src/objects/intl-objects.h | 55 +- deps/v8/src/objects/intl-objects.tq | 158 +- deps/v8/src/objects/js-array-buffer-inl.h | 157 +- deps/v8/src/objects/js-array-buffer.cc | 53 +- deps/v8/src/objects/js-array-buffer.h | 275 +- deps/v8/src/objects/js-array-buffer.tq | 12 +- deps/v8/src/objects/js-array-inl.h | 71 +- deps/v8/src/objects/js-array.h | 100 +- deps/v8/src/objects/js-array.tq | 11 +- .../objects/js-atomics-synchronization-inl.h | 42 +- .../src/objects/js-atomics-synchronization.cc | 15 +- .../src/objects/js-atomics-synchronization.h | 87 +- .../src/objects/js-atomics-synchronization.tq | 4 +- deps/v8/src/objects/js-break-iterator-inl.h | 42 +- deps/v8/src/objects/js-break-iterator.cc | 47 +- deps/v8/src/objects/js-break-iterator.h | 76 +- deps/v8/src/objects/js-break-iterator.tq | 4 +- deps/v8/src/objects/js-collator-inl.h | 27 +- deps/v8/src/objects/js-collator.cc | 8 +- deps/v8/src/objects/js-collator.h | 39 +- deps/v8/src/objects/js-collator.tq | 1 + deps/v8/src/objects/js-collection-inl.h | 29 +- .../src/objects/js-collection-iterator-inl.h | 15 +- deps/v8/src/objects/js-collection-iterator.h | 35 +- deps/v8/src/objects/js-collection-iterator.tq | 1 + deps/v8/src/objects/js-collection.h | 74 +- deps/v8/src/objects/js-collection.tq | 14 +- .../src/objects/js-data-object-builder-inl.h | 630 ++++ deps/v8/src/objects/js-data-object-builder.cc | 88 + deps/v8/src/objects/js-data-object-builder.h | 190 + deps/v8/src/objects/js-date-time-format-inl.h | 51 +- deps/v8/src/objects/js-date-time-format.cc | 313 +- deps/v8/src/objects/js-date-time-format.h | 76 +- deps/v8/src/objects/js-date-time-format.tq | 1 + deps/v8/src/objects/js-display-names-inl.h | 16 +- deps/v8/src/objects/js-display-names.cc | 16 +- deps/v8/src/objects/js-display-names.h | 32 +- deps/v8/src/objects/js-display-names.tq | 1 + deps/v8/src/objects/js-disposable-stack-inl.h | 59 +- deps/v8/src/objects/js-disposable-stack.h | 56 +- deps/v8/src/objects/js-disposable-stack.tq | 3 + deps/v8/src/objects/js-duration-format-inl.h | 36 +- deps/v8/src/objects/js-duration-format.cc | 12 +- deps/v8/src/objects/js-duration-format.h | 47 +- deps/v8/src/objects/js-duration-format.tq | 1 + deps/v8/src/objects/js-function-inl.h | 328 +- deps/v8/src/objects/js-function.cc | 75 +- deps/v8/src/objects/js-function.h | 205 +- deps/v8/src/objects/js-function.tq | 33 +- deps/v8/src/objects/js-generator-inl.h | 130 +- deps/v8/src/objects/js-generator.h | 113 +- deps/v8/src/objects/js-generator.tq | 10 + deps/v8/src/objects/js-iterator-helpers-inl.h | 183 +- deps/v8/src/objects/js-iterator-helpers.h | 194 +- deps/v8/src/objects/js-iterator-helpers.tq | 27 + deps/v8/src/objects/js-list-format-inl.h | 20 +- deps/v8/src/objects/js-list-format.cc | 12 +- deps/v8/src/objects/js-list-format.h | 44 +- deps/v8/src/objects/js-list-format.tq | 1 + deps/v8/src/objects/js-locale-inl.h | 13 +- deps/v8/src/objects/js-locale.cc | 40 +- deps/v8/src/objects/js-locale.h | 21 +- deps/v8/src/objects/js-locale.tq | 1 + deps/v8/src/objects/js-number-format-inl.h | 30 +- deps/v8/src/objects/js-number-format.cc | 92 +- deps/v8/src/objects/js-number-format.h | 58 +- deps/v8/src/objects/js-number-format.tq | 1 + deps/v8/src/objects/js-objects-inl.h | 348 +- deps/v8/src/objects/js-objects.cc | 426 ++- deps/v8/src/objects/js-objects.h | 525 ++- deps/v8/src/objects/js-objects.tq | 17 +- deps/v8/src/objects/js-plural-rules-inl.h | 33 +- deps/v8/src/objects/js-plural-rules.cc | 19 +- deps/v8/src/objects/js-plural-rules.h | 51 +- deps/v8/src/objects/js-plural-rules.tq | 1 + deps/v8/src/objects/js-promise-inl.h | 22 +- deps/v8/src/objects/js-promise.h | 54 +- deps/v8/src/objects/js-promise.tq | 6 +- deps/v8/src/objects/js-proxy-inl.h | 25 +- deps/v8/src/objects/js-proxy.h | 85 +- deps/v8/src/objects/js-proxy.tq | 2 +- deps/v8/src/objects/js-raw-json-inl.h | 2 - deps/v8/src/objects/js-raw-json.cc | 4 +- deps/v8/src/objects/js-raw-json.h | 21 +- deps/v8/src/objects/js-raw-json.tq | 1 + deps/v8/src/objects/js-regexp-inl.h | 252 +- .../objects/js-regexp-string-iterator-inl.h | 48 +- .../src/objects/js-regexp-string-iterator.h | 31 +- .../src/objects/js-regexp-string-iterator.tq | 1 + deps/v8/src/objects/js-regexp.cc | 217 +- deps/v8/src/objects/js-regexp.h | 289 +- deps/v8/src/objects/js-regexp.tq | 36 +- .../src/objects/js-relative-time-format-inl.h | 31 +- .../v8/src/objects/js-relative-time-format.cc | 9 +- deps/v8/src/objects/js-relative-time-format.h | 53 +- .../v8/src/objects/js-relative-time-format.tq | 1 + deps/v8/src/objects/js-segment-iterator-inl.h | 60 +- deps/v8/src/objects/js-segment-iterator.cc | 38 +- deps/v8/src/objects/js-segment-iterator.h | 117 +- deps/v8/src/objects/js-segment-iterator.tq | 6 +- deps/v8/src/objects/js-segmenter-inl.h | 20 +- deps/v8/src/objects/js-segmenter.cc | 2 +- deps/v8/src/objects/js-segmenter.h | 37 +- deps/v8/src/objects/js-segmenter.tq | 1 + deps/v8/src/objects/js-segments-inl.h | 25 +- deps/v8/src/objects/js-segments.cc | 41 +- deps/v8/src/objects/js-segments.h | 46 +- deps/v8/src/objects/js-segments.tq | 4 +- deps/v8/src/objects/js-shadow-realm-inl.h | 10 +- deps/v8/src/objects/js-shadow-realm.h | 13 +- deps/v8/src/objects/js-shadow-realm.tq | 1 + deps/v8/src/objects/js-shared-array-inl.h | 2 - deps/v8/src/objects/js-shared-array.h | 18 +- deps/v8/src/objects/js-shared-array.tq | 1 + deps/v8/src/objects/js-struct-inl.h | 4 - deps/v8/src/objects/js-struct.cc | 90 +- deps/v8/src/objects/js-struct.h | 34 +- deps/v8/src/objects/js-struct.tq | 2 + deps/v8/src/objects/js-temporal-helpers.cc | 12 +- deps/v8/src/objects/js-temporal-helpers.h | 10 +- deps/v8/src/objects/js-temporal-objects-inl.h | 69 +- deps/v8/src/objects/js-temporal-objects.cc | 485 +-- deps/v8/src/objects/js-temporal-objects.h | 374 +- deps/v8/src/objects/js-temporal-objects.tq | 8 + deps/v8/src/objects/js-weak-refs-inl.h | 67 +- deps/v8/src/objects/js-weak-refs.cc | 2 +- deps/v8/src/objects/js-weak-refs.h | 84 +- deps/v8/src/objects/js-weak-refs.tq | 2 + deps/v8/src/objects/keys.cc | 92 +- deps/v8/src/objects/keys.h | 2 +- deps/v8/src/objects/literal-objects-inl.h | 68 +- deps/v8/src/objects/literal-objects.cc | 12 +- deps/v8/src/objects/literal-objects.h | 52 +- deps/v8/src/objects/literal-objects.tq | 6 +- deps/v8/src/objects/lookup-cache.cc | 2 +- deps/v8/src/objects/lookup-cache.h | 2 +- deps/v8/src/objects/lookup-inl.h | 2 +- deps/v8/src/objects/lookup.cc | 117 +- deps/v8/src/objects/lookup.h | 10 +- deps/v8/src/objects/managed-inl.h | 19 +- deps/v8/src/objects/managed.cc | 29 +- deps/v8/src/objects/managed.h | 131 +- deps/v8/src/objects/map-inl.h | 662 +++- deps/v8/src/objects/map-updater.cc | 66 +- deps/v8/src/objects/map-word-inl.h | 84 + deps/v8/src/objects/map-word.h | 100 + deps/v8/src/objects/map.cc | 288 +- deps/v8/src/objects/map.h | 305 +- deps/v8/src/objects/map.tq | 35 +- deps/v8/src/objects/megadom-handler-inl.h | 28 +- deps/v8/src/objects/megadom-handler.h | 32 +- deps/v8/src/objects/megadom-handler.tq | 2 +- deps/v8/src/objects/microtask-inl.h | 24 +- deps/v8/src/objects/microtask.h | 56 +- deps/v8/src/objects/microtask.tq | 12 +- deps/v8/src/objects/module-inl.h | 68 +- deps/v8/src/objects/module.cc | 34 +- deps/v8/src/objects/module.h | 101 +- deps/v8/src/objects/module.tq | 3 + deps/v8/src/objects/name-inl.h | 5 +- deps/v8/src/objects/number-string-cache-inl.h | 6 +- deps/v8/src/objects/number-string-cache.h | 9 +- deps/v8/src/objects/object-list-macros.h | 28 +- deps/v8/src/objects/object-macros-undef.h | 2 - deps/v8/src/objects/object-macros.h | 314 +- deps/v8/src/objects/object-predicates-inl.h | 299 ++ deps/v8/src/objects/object-predicates.h | 118 + .../objects/objects-body-descriptors-inl.h | 850 ++++- .../v8/src/objects/objects-body-descriptors.h | 12 + deps/v8/src/objects/objects-definitions.h | 1 + deps/v8/src/objects/objects-inl.h | 580 +-- deps/v8/src/objects/objects.cc | 268 +- deps/v8/src/objects/objects.h | 197 +- deps/v8/src/objects/option-utils.cc | 10 +- deps/v8/src/objects/option-utils.h | 16 +- deps/v8/src/objects/ordered-hash-table-inl.h | 27 +- deps/v8/src/objects/ordered-hash-table.cc | 118 +- deps/v8/src/objects/ordered-hash-table.h | 149 +- deps/v8/src/objects/ordered-hash-table.tq | 17 +- deps/v8/src/objects/promise.h | 4 +- deps/v8/src/objects/property-array-inl.h | 130 +- deps/v8/src/objects/property-array.h | 70 +- deps/v8/src/objects/property-array.tq | 3 + deps/v8/src/objects/property-cell-inl.h | 56 +- deps/v8/src/objects/property-cell.h | 52 +- deps/v8/src/objects/property-cell.tq | 1 + .../src/objects/property-descriptor-object.h | 2 +- deps/v8/src/objects/property-descriptor.cc | 40 +- deps/v8/src/objects/property-details.h | 85 +- deps/v8/src/objects/property.cc | 44 +- deps/v8/src/objects/property.h | 37 +- deps/v8/src/objects/prototype-info-inl.h | 107 +- deps/v8/src/objects/prototype-info.h | 69 +- deps/v8/src/objects/prototype-info.tq | 1 + deps/v8/src/objects/regexp-match-info.cc | 13 +- deps/v8/src/objects/regexp-match-info.h | 7 +- deps/v8/src/objects/regexp-match-info.tq | 4 +- deps/v8/src/objects/scope-info-inl.h | 417 ++- deps/v8/src/objects/scope-info.cc | 291 +- deps/v8/src/objects/scope-info.h | 253 +- deps/v8/src/objects/scope-info.tq | 14 +- deps/v8/src/objects/script-inl.h | 213 +- deps/v8/src/objects/script.cc | 65 +- deps/v8/src/objects/script.h | 149 +- deps/v8/src/objects/script.tq | 2 + .../v8/src/objects/shared-function-info-inl.h | 352 +- deps/v8/src/objects/shared-function-info.cc | 107 +- deps/v8/src/objects/shared-function-info.h | 257 +- deps/v8/src/objects/shared-function-info.tq | 8 +- deps/v8/src/objects/simd.cc | 310 +- deps/v8/src/objects/slots-inl.h | 4 - deps/v8/src/objects/slots.h | 30 +- deps/v8/src/objects/smi.h | 2 +- deps/v8/src/objects/sort-state.h | 53 + deps/v8/src/objects/source-text-module-inl.h | 161 +- deps/v8/src/objects/source-text-module.cc | 97 +- deps/v8/src/objects/source-text-module.h | 174 +- deps/v8/src/objects/source-text-module.tq | 3 + .../src/objects/string-forwarding-table-inl.h | 15 +- .../v8/src/objects/string-forwarding-table.cc | 10 +- deps/v8/src/objects/string-forwarding-table.h | 8 +- deps/v8/src/objects/string-inl.h | 133 +- deps/v8/src/objects/string-table.cc | 111 +- deps/v8/src/objects/string-table.h | 17 +- deps/v8/src/objects/string.cc | 99 +- deps/v8/src/objects/string.h | 81 +- deps/v8/src/objects/struct-inl.h | 2 - deps/v8/src/objects/struct.h | 21 +- deps/v8/src/objects/struct.tq | 1 + .../src/objects/swiss-name-dictionary-inl.h | 67 +- deps/v8/src/objects/swiss-name-dictionary.h | 18 +- deps/v8/src/objects/swiss-name-dictionary.tq | 2 +- deps/v8/src/objects/synthetic-module-inl.h | 22 +- deps/v8/src/objects/synthetic-module.cc | 3 +- deps/v8/src/objects/synthetic-module.h | 31 +- deps/v8/src/objects/synthetic-module.tq | 1 + deps/v8/src/objects/tagged-field-inl.h | 42 +- deps/v8/src/objects/tagged-field.h | 32 + deps/v8/src/objects/tagged.h | 608 +-- deps/v8/src/objects/template-objects.cc | 6 +- deps/v8/src/objects/template-objects.h | 2 +- deps/v8/src/objects/templates-inl.h | 328 +- deps/v8/src/objects/templates.cc | 45 +- deps/v8/src/objects/templates.h | 248 +- deps/v8/src/objects/templates.tq | 12 +- deps/v8/src/objects/transitions-inl.h | 30 +- deps/v8/src/objects/transitions.cc | 78 +- deps/v8/src/objects/transitions.h | 18 +- deps/v8/src/objects/trusted-object-inl.h | 69 +- deps/v8/src/objects/trusted-object.h | 64 +- deps/v8/src/objects/trusted-object.tq | 4 +- deps/v8/src/objects/trusted-pointer-inl.h | 89 +- deps/v8/src/objects/trusted-pointer.h | 41 +- deps/v8/src/objects/turbofan-types-inl.h | 43 + deps/v8/src/objects/turbofan-types.h | 107 + deps/v8/src/objects/turbofan-types.tq | 24 +- deps/v8/src/objects/turboshaft-types-inl.h | 110 +- deps/v8/src/objects/turboshaft-types.h | 203 +- deps/v8/src/objects/turboshaft-types.tq | 40 +- deps/v8/src/objects/union.h | 14 +- deps/v8/src/objects/value-serializer.cc | 224 +- deps/v8/src/objects/value-serializer.h | 2 + deps/v8/src/objects/visitors.h | 4 + deps/v8/src/parsing/literal-buffer.cc | 17 +- deps/v8/src/parsing/literal-buffer.h | 18 +- deps/v8/src/parsing/parse-info.cc | 12 +- deps/v8/src/parsing/parse-info.h | 11 +- deps/v8/src/parsing/parser-base.h | 158 +- deps/v8/src/parsing/parser.cc | 131 +- deps/v8/src/parsing/parser.h | 7 +- .../pending-compilation-error-handler.cc | 8 + deps/v8/src/parsing/preparser.cc | 12 +- deps/v8/src/parsing/preparser.h | 5 +- .../src/parsing/scanner-character-streams.cc | 12 +- deps/v8/src/parsing/scanner.cc | 10 +- deps/v8/src/parsing/scanner.h | 6 +- deps/v8/src/profiler/DIR_METADATA | 7 +- deps/v8/src/profiler/allocation-tracker.cc | 6 +- deps/v8/src/profiler/cpu-profiler.cc | 3 +- deps/v8/src/profiler/heap-profiler.cc | 52 +- deps/v8/src/profiler/heap-profiler.h | 26 +- deps/v8/src/profiler/heap-snapshot-common.h | 10 +- .../profiler/heap-snapshot-generator-inl.h | 75 - .../src/profiler/heap-snapshot-generator.cc | 757 ++-- .../v8/src/profiler/heap-snapshot-generator.h | 102 +- deps/v8/src/profiler/output-stream-writer.cc | 75 + deps/v8/src/profiler/output-stream-writer.h | 5 +- deps/v8/src/profiler/profile-generator.cc | 19 +- deps/v8/src/profiler/profile-generator.h | 6 +- deps/v8/src/profiler/profiler-listener.cc | 13 +- deps/v8/src/profiler/profiler-listener.h | 4 +- deps/v8/src/profiler/strings-storage.cc | 21 +- deps/v8/src/profiler/strings-storage.h | 8 +- .../regexp/arm/regexp-macro-assembler-arm.cc | 70 +- .../regexp/arm/regexp-macro-assembler-arm.h | 6 +- .../arm64/regexp-macro-assembler-arm64.cc | 102 +- .../arm64/regexp-macro-assembler-arm64.h | 6 +- .../experimental/experimental-bytecode.cc | 64 +- .../experimental/experimental-bytecode.h | 117 +- .../experimental/experimental-compiler.cc | 296 +- .../experimental/experimental-compiler.h | 14 +- .../experimental/experimental-interpreter.cc | 202 +- .../experimental/experimental-interpreter.h | 15 +- .../src/regexp/experimental/experimental.cc | 73 +- .../v8/src/regexp/experimental/experimental.h | 11 +- deps/v8/src/regexp/gen-regexp-special-case.cc | 18 +- .../ia32/regexp-macro-assembler-ia32.cc | 75 +- .../regexp/ia32/regexp-macro-assembler-ia32.h | 6 +- .../loong64/regexp-macro-assembler-loong64.cc | 13 +- .../loong64/regexp-macro-assembler-loong64.h | 6 +- .../mips64/regexp-macro-assembler-mips64.cc | 51 +- .../mips64/regexp-macro-assembler-mips64.h | 6 +- .../regexp/ppc/regexp-macro-assembler-ppc.cc | 42 +- .../regexp/ppc/regexp-macro-assembler-ppc.h | 6 +- deps/v8/src/regexp/regexp-ast-printer.cc | 81 +- deps/v8/src/regexp/regexp-ast-printer.h | 39 +- deps/v8/src/regexp/regexp-ast.cc | 186 +- deps/v8/src/regexp/regexp-ast.h | 329 +- .../v8/src/regexp/regexp-bytecode-analysis.cc | 513 +-- deps/v8/src/regexp/regexp-bytecode-analysis.h | 107 +- .../regexp/regexp-bytecode-generator-inl.h | 20 +- .../src/regexp/regexp-bytecode-generator.cc | 416 +-- .../v8/src/regexp/regexp-bytecode-generator.h | 49 +- .../src/regexp/regexp-bytecode-iterator-inl.h | 26 +- .../v8/src/regexp/regexp-bytecode-iterator.cc | 22 +- deps/v8/src/regexp/regexp-bytecode-iterator.h | 17 +- .../v8/src/regexp/regexp-bytecode-peephole.cc | 205 +- deps/v8/src/regexp/regexp-bytecode-peephole.h | 15 +- deps/v8/src/regexp/regexp-bytecodes-inl.h | 137 +- deps/v8/src/regexp/regexp-bytecodes.cc | 43 +- deps/v8/src/regexp/regexp-bytecodes.h | 85 +- deps/v8/src/regexp/regexp-code-generator.cc | 80 +- deps/v8/src/regexp/regexp-code-generator.h | 24 +- deps/v8/src/regexp/regexp-compiler-tonode.cc | 487 ++- deps/v8/src/regexp/regexp-compiler.cc | 465 +-- deps/v8/src/regexp/regexp-compiler.h | 66 +- deps/v8/src/regexp/regexp-dotprinter.cc | 26 +- deps/v8/src/regexp/regexp-dotprinter.h | 6 +- deps/v8/src/regexp/regexp-error.cc | 10 +- deps/v8/src/regexp/regexp-error.h | 12 +- deps/v8/src/regexp/regexp-flags.h | 32 +- deps/v8/src/regexp/regexp-graph-printer.cc | 158 +- deps/v8/src/regexp/regexp-graph-printer.h | 62 +- deps/v8/src/regexp/regexp-interpreter.cc | 60 +- deps/v8/src/regexp/regexp-interpreter.h | 3 + .../regexp/regexp-macro-assembler-tracer.cc | 69 +- .../regexp/regexp-macro-assembler-tracer.h | 10 +- deps/v8/src/regexp/regexp-macro-assembler.cc | 86 +- deps/v8/src/regexp/regexp-macro-assembler.h | 17 +- deps/v8/src/regexp/regexp-node-printer.cc | 40 +- deps/v8/src/regexp/regexp-node-printer.h | 25 +- deps/v8/src/regexp/regexp-nodes.h | 271 +- deps/v8/src/regexp/regexp-parser.cc | 860 +++-- deps/v8/src/regexp/regexp-parser.h | 14 +- deps/v8/src/regexp/regexp-printer.cc | 22 +- deps/v8/src/regexp/regexp-printer.h | 83 +- deps/v8/src/regexp/regexp-result-vector.cc | 19 +- deps/v8/src/regexp/regexp-result-vector.h | 12 +- deps/v8/src/regexp/regexp-stack.cc | 44 +- deps/v8/src/regexp/regexp-stack.h | 42 +- deps/v8/src/regexp/regexp-utils.cc | 38 +- deps/v8/src/regexp/regexp-utils.h | 9 +- deps/v8/src/regexp/regexp.cc | 1069 ++++-- deps/v8/src/regexp/regexp.h | 86 +- .../riscv/regexp-macro-assembler-riscv.cc | 17 +- .../riscv/regexp-macro-assembler-riscv.h | 6 +- .../s390/regexp-macro-assembler-s390.cc | 16 +- .../regexp/s390/regexp-macro-assembler-s390.h | 6 +- deps/v8/src/regexp/special-case.h | 4 +- .../regexp/x64/regexp-macro-assembler-x64.cc | 110 +- .../regexp/x64/regexp-macro-assembler-x64.h | 6 +- deps/v8/src/roots/roots-inl.h | 22 +- deps/v8/src/roots/roots.cc | 11 +- deps/v8/src/roots/roots.h | 43 +- deps/v8/src/roots/static-roots-intl-nowasm.h | 2228 +++++------ deps/v8/src/roots/static-roots-intl-wasm.h | 2278 ++++++------ .../v8/src/roots/static-roots-nointl-nowasm.h | 1930 +++++----- deps/v8/src/roots/static-roots-nointl-wasm.h | 1980 +++++----- deps/v8/src/runtime/runtime-array.cc | 40 +- deps/v8/src/runtime/runtime-atomics.cc | 14 +- deps/v8/src/runtime/runtime-classes.cc | 28 +- deps/v8/src/runtime/runtime-compiler.cc | 140 +- deps/v8/src/runtime/runtime-debug.cc | 24 +- deps/v8/src/runtime/runtime-forin.cc | 12 +- deps/v8/src/runtime/runtime-generator.cc | 2 +- deps/v8/src/runtime/runtime-internal.cc | 50 +- deps/v8/src/runtime/runtime-intl.cc | 4 +- deps/v8/src/runtime/runtime-literals.cc | 314 +- deps/v8/src/runtime/runtime-object.cc | 85 +- deps/v8/src/runtime/runtime-operators.cc | 19 +- deps/v8/src/runtime/runtime-promise.cc | 46 +- deps/v8/src/runtime/runtime-proxy.cc | 7 +- deps/v8/src/runtime/runtime-regexp.cc | 257 +- deps/v8/src/runtime/runtime-scopes.cc | 35 +- deps/v8/src/runtime/runtime-strings.cc | 90 +- deps/v8/src/runtime/runtime-test-wasm.cc | 272 +- deps/v8/src/runtime/runtime-test.cc | 99 +- deps/v8/src/runtime/runtime-trace.cc | 2 +- deps/v8/src/runtime/runtime-typedarray.cc | 5 +- deps/v8/src/runtime/runtime-wasm.cc | 522 ++- deps/v8/src/runtime/runtime.cc | 3 + deps/v8/src/runtime/runtime.h | 33 +- deps/v8/src/sandbox/bytecode-verifier.cc | 23 +- deps/v8/src/sandbox/code-pointer-inl.h | 53 - deps/v8/src/sandbox/code-pointer-table-inl.h | 60 +- deps/v8/src/sandbox/code-pointer-table.cc | 18 + deps/v8/src/sandbox/code-pointer-table.h | 46 +- deps/v8/src/sandbox/code-pointer.h | 30 - deps/v8/src/sandbox/cppheap-pointer-inl.h | 21 + deps/v8/src/sandbox/cppheap-pointer-table.cc | 21 + deps/v8/src/sandbox/cppheap-pointer-table.h | 8 + deps/v8/src/sandbox/cppheap-pointer.h | 33 + .../src/sandbox/external-entity-table-inl.h | 2 + deps/v8/src/sandbox/external-pointer-inl.h | 118 +- deps/v8/src/sandbox/external-pointer-table.cc | 21 + deps/v8/src/sandbox/external-pointer-table.h | 8 + deps/v8/src/sandbox/external-pointer.h | 97 +- deps/v8/src/sandbox/external-strings-cage.cc | 4 + deps/v8/src/sandbox/hardware-support.h | 14 +- deps/v8/src/sandbox/indirect-pointer-inl.h | 9 +- deps/v8/src/sandbox/indirect-pointer-tag.h | 17 +- deps/v8/src/sandbox/isolate-inl.h | 9 +- deps/v8/src/sandbox/isolate.h | 3 +- deps/v8/src/sandbox/js-dispatch-table-inl.h | 15 - deps/v8/src/sandbox/js-dispatch-table.cc | 20 + deps/v8/src/sandbox/js-dispatch-table.h | 23 +- deps/v8/src/sandbox/sandbox.cc | 79 +- deps/v8/src/sandbox/sandbox.h | 11 +- deps/v8/src/sandbox/testing.cc | 60 +- deps/v8/src/sandbox/trap-fuzzer.cc | 509 +++ deps/v8/src/sandbox/trap-fuzzer.h | 145 + .../src/sandbox/trusted-pointer-table-inl.h | 31 +- deps/v8/src/sandbox/trusted-pointer-table.cc | 33 + deps/v8/src/sandbox/trusted-pointer-table.h | 24 + deps/v8/src/snapshot/code-serializer.cc | 7 +- deps/v8/src/snapshot/context-serializer.cc | 9 +- deps/v8/src/snapshot/deserializer.cc | 35 +- deps/v8/src/snapshot/deserializer.h | 8 +- .../snapshot/embedded/embedded-file-writer.cc | 170 +- .../snapshot/embedded/embedded-file-writer.h | 8 + .../platform-embedded-file-writer-generic.cc | 7 +- deps/v8/src/snapshot/mksnapshot.cc | 7 +- .../v8/src/snapshot/read-only-deserializer.cc | 40 +- deps/v8/src/snapshot/read-only-serializer.cc | 37 +- deps/v8/src/snapshot/serializer.cc | 34 +- deps/v8/src/snapshot/serializer.h | 2 +- .../src/snapshot/shared-heap-deserializer.cc | 4 +- deps/v8/src/snapshot/snapshot-data.cc | 5 +- deps/v8/src/snapshot/snapshot-source-sink.cc | 4 +- deps/v8/src/snapshot/snapshot-source-sink.h | 18 +- deps/v8/src/snapshot/snapshot.cc | 6 +- deps/v8/src/snapshot/startup-deserializer.cc | 4 +- deps/v8/src/snapshot/startup-serializer.cc | 7 +- deps/v8/src/snapshot/static-roots-gen.cc | 48 +- deps/v8/src/snapshot/static-roots-gen.h | 1 + deps/v8/src/strings/char-predicates-inl.h | 16 +- deps/v8/src/strings/char-predicates.cc | 7 +- deps/v8/src/strings/char-predicates.h | 7 +- deps/v8/src/strings/string-builder-inl.h | 2 +- deps/v8/src/strings/string-builder.cc | 45 +- deps/v8/src/strings/string-builder.h | 19 +- deps/v8/src/strings/string-hasher-inl.h | 2 +- deps/v8/src/strings/string-stream.cc | 16 +- deps/v8/src/strings/unicode.h | 2 +- deps/v8/src/torque/constants.h | 16 +- deps/v8/src/torque/cpp-builder.h | 6 +- deps/v8/src/torque/global-context.cc | 1 + deps/v8/src/torque/global-context.h | 3 + deps/v8/src/torque/implementation-visitor.cc | 1400 +------ deps/v8/src/torque/implementation-visitor.h | 4 - deps/v8/src/torque/instance-type-generator.cc | 82 +- deps/v8/src/torque/source-positions.h | 2 +- deps/v8/src/torque/torque-code-generator.cc | 4 +- deps/v8/src/torque/torque-compiler.cc | 10 +- deps/v8/src/torque/torque-compiler.h | 3 + deps/v8/src/torque/torque-parser.cc | 31 +- deps/v8/src/torque/torque.cc | 4 +- deps/v8/src/torque/tsa-generator.cc | 587 ++- deps/v8/src/torque/type-visitor.cc | 38 +- deps/v8/src/torque/types.cc | 22 +- deps/v8/src/torque/types.h | 42 +- deps/v8/src/torque/utils.h | 2 +- deps/v8/src/tracing/code-data-source.cc | 26 +- deps/v8/src/tracing/code-data-source.h | 8 +- deps/v8/src/tracing/code-trace-context.h | 8 +- deps/v8/src/tracing/perfetto-logger.cc | 59 +- deps/v8/src/tracing/perfetto-logger.h | 15 +- deps/v8/src/tracing/trace-event-no-perfetto.h | 8 +- deps/v8/src/tracing/trace-event.h | 3 + deps/v8/src/trap-handler/handler-inside.cc | 22 +- deps/v8/src/trap-handler/handler-outside.cc | 94 +- deps/v8/src/trap-handler/handler-shared.cc | 19 + .../src/trap-handler/trap-handler-internal.h | 28 +- .../src/trap-handler/trap-handler-simulator.h | 2 +- deps/v8/src/trap-handler/trap-handler.h | 23 +- deps/v8/src/utils/bit-vector.h | 190 +- deps/v8/src/utils/boxed-float.h | 15 + deps/v8/src/utils/utils.cc | 4 +- deps/v8/src/wasm/DEPS | 31 +- .../baseline/arm/liftoff-assembler-arm-inl.h | 160 +- .../arm64/liftoff-assembler-arm64-inl.h | 237 +- .../ia32/liftoff-assembler-ia32-inl.h | 139 +- .../wasm/baseline/liftoff-assembler-defs.h | 38 +- .../src/wasm/baseline/liftoff-assembler-inl.h | 13 +- .../v8/src/wasm/baseline/liftoff-assembler.cc | 124 +- deps/v8/src/wasm/baseline/liftoff-assembler.h | 143 +- deps/v8/src/wasm/baseline/liftoff-compiler.cc | 1503 ++++---- deps/v8/src/wasm/baseline/liftoff-register.h | 289 +- deps/v8/src/wasm/baseline/liftoff-varstate.h | 1 + .../loong64/liftoff-assembler-loong64-inl.h | 410 ++- .../mips64/liftoff-assembler-mips64-inl.h | 165 +- deps/v8/src/wasm/baseline/parallel-move.h | 8 +- .../baseline/ppc/liftoff-assembler-ppc-inl.h | 390 +- .../riscv/liftoff-assembler-riscv-inl.h | 755 ++-- .../riscv/liftoff-assembler-riscv32-inl.h | 191 +- .../riscv/liftoff-assembler-riscv64-inl.h | 314 +- .../s390/liftoff-assembler-s390-inl.h | 179 +- .../baseline/x64/liftoff-assembler-x64-inl.h | 341 +- deps/v8/src/wasm/c-api.cc | 88 +- deps/v8/src/wasm/c-api.h | 11 +- deps/v8/src/wasm/canonical-types.cc | 89 +- deps/v8/src/wasm/canonical-types.h | 76 +- .../v8/src/wasm/compilation-environment-inl.h | 4 - deps/v8/src/wasm/compilation-environment.h | 20 +- .../src/wasm/compilation-hints-generation.cc | 18 +- .../src/wasm/constant-expression-interface.cc | 166 +- .../src/wasm/constant-expression-interface.h | 5 + deps/v8/src/wasm/constant-expression.cc | 12 +- deps/v8/src/wasm/decoder.h | 22 +- deps/v8/src/wasm/effect-handler.h | 33 + deps/v8/src/wasm/function-body-decoder-impl.h | 542 ++- deps/v8/src/wasm/function-body-decoder.cc | 19 +- deps/v8/src/wasm/function-body-decoder.h | 12 +- deps/v8/src/wasm/function-compiler.cc | 32 +- deps/v8/src/wasm/function-compiler.h | 24 +- .../wasm/fuzzing/random-module-generation.cc | 369 +- deps/v8/src/wasm/inlining-tree.h | 13 +- deps/v8/src/wasm/interpreter/OWNERS | 4 + .../arm64/interpreter-builtins-arm64.cc | 2403 ++++++++---- .../wasm/interpreter/instruction-handlers.h | 2553 ++++++------- .../riscv/interpreter-builtins-riscv.cc | 902 +---- .../wasm/interpreter/wasm-interpreter-inl.h | 8 + .../interpreter/wasm-interpreter-objects.cc | 18 +- .../interpreter/wasm-interpreter-objects.h | 8 +- .../wasm-interpreter-runtime-inl.h | 92 +- .../interpreter/wasm-interpreter-runtime.cc | 284 +- .../interpreter/wasm-interpreter-runtime.h | 75 +- .../wasm/interpreter/wasm-interpreter-simd.cc | 10 +- .../src/wasm/interpreter/wasm-interpreter.cc | 1734 +++++---- .../src/wasm/interpreter/wasm-interpreter.h | 37 +- .../x64/interpreter-builtins-x64.cc | 871 +---- deps/v8/src/wasm/jump-table-assembler.cc | 10 +- deps/v8/src/wasm/jump-table-assembler.h | 2 - deps/v8/src/wasm/leb-helper.h | 34 +- deps/v8/src/wasm/local-decl-encoder.cc | 37 +- deps/v8/src/wasm/local-decl-encoder.h | 17 +- deps/v8/src/wasm/module-compiler.cc | 232 +- deps/v8/src/wasm/module-compiler.h | 8 +- deps/v8/src/wasm/module-decoder-impl.h | 810 ++-- deps/v8/src/wasm/module-decoder.cc | 18 +- deps/v8/src/wasm/module-decoder.h | 3 - deps/v8/src/wasm/module-instantiate.cc | 694 ++-- deps/v8/src/wasm/module-instantiate.h | 2 - deps/v8/src/wasm/names-provider.cc | 19 +- deps/v8/src/wasm/names-provider.h | 2 - deps/v8/src/wasm/object-access.h | 83 - deps/v8/src/wasm/signature-hashing.h | 64 +- deps/v8/src/wasm/simd-shuffle.cc | 12 +- deps/v8/src/wasm/simd-shuffle.h | 5 +- deps/v8/src/wasm/stacks.cc | 34 +- deps/v8/src/wasm/stacks.h | 14 + deps/v8/src/wasm/streaming-decoder.cc | 8 + deps/v8/src/wasm/streaming-decoder.h | 4 +- deps/v8/src/wasm/struct-types.h | 23 +- deps/v8/src/wasm/sync-streaming-decoder.cc | 1 + .../src/wasm/turboshaft-graph-interface-inl.h | 15 +- .../v8/src/wasm/turboshaft-graph-interface.cc | 1867 ++++++---- deps/v8/src/wasm/turboshaft-graph-interface.h | 9 +- deps/v8/src/wasm/value-type.cc | 34 +- deps/v8/src/wasm/value-type.h | 105 +- deps/v8/src/wasm/wasm-builtin-list.h | 15 + deps/v8/src/wasm/wasm-code-manager.cc | 187 +- deps/v8/src/wasm/wasm-code-manager.h | 132 +- .../v8/src/wasm/wasm-code-pointer-table-inl.h | 20 - deps/v8/src/wasm/wasm-code-pointer-table.h | 14 +- deps/v8/src/wasm/wasm-constants.h | 27 +- deps/v8/src/wasm/wasm-debug.cc | 167 +- deps/v8/src/wasm/wasm-debug.h | 2 +- deps/v8/src/wasm/wasm-disassembler-impl.h | 2 +- deps/v8/src/wasm/wasm-disassembler.cc | 25 +- deps/v8/src/wasm/wasm-engine-globals.h | 37 + deps/v8/src/wasm/wasm-engine.cc | 151 +- deps/v8/src/wasm/wasm-engine.h | 56 +- deps/v8/src/wasm/wasm-export-wrapper-cache.cc | 42 +- deps/v8/src/wasm/wasm-export-wrapper-cache.h | 19 +- deps/v8/src/wasm/wasm-external-refs.cc | 291 +- deps/v8/src/wasm/wasm-external-refs.h | 10 +- deps/v8/src/wasm/wasm-feature-flags.h | 66 +- deps/v8/src/wasm/wasm-features.h | 21 +- deps/v8/src/wasm/wasm-init-expr.h | 2 - deps/v8/src/wasm/wasm-js.cc | 548 +-- deps/v8/src/wasm/wasm-js.h | 8 - deps/v8/src/wasm/wasm-limits.h | 11 + deps/v8/src/wasm/wasm-linkage.h | 72 +- deps/v8/src/wasm/wasm-module-builder.cc | 8 +- deps/v8/src/wasm/wasm-module-builder.h | 8 +- deps/v8/src/wasm/wasm-module.cc | 112 +- deps/v8/src/wasm/wasm-module.h | 83 +- deps/v8/src/wasm/wasm-objects-inl.h | 1207 ++++-- deps/v8/src/wasm/wasm-objects.cc | 1113 +++--- deps/v8/src/wasm/wasm-objects.h | 1356 +++++-- deps/v8/src/wasm/wasm-objects.tq | 67 +- deps/v8/src/wasm/wasm-opcodes-inl.h | 106 +- deps/v8/src/wasm/wasm-opcodes.cc | 5 + deps/v8/src/wasm/wasm-opcodes.h | 31 +- deps/v8/src/wasm/wasm-result.cc | 1 - deps/v8/src/wasm/wasm-result.h | 2 - deps/v8/src/wasm/wasm-serialization.cc | 73 +- deps/v8/src/wasm/wasm-subtyping.cc | 15 +- deps/v8/src/wasm/wasm-subtyping.h | 6 +- deps/v8/src/wasm/wasm-tracing.h | 7 - deps/v8/src/wasm/wasm-value.h | 5 +- deps/v8/src/wasm/wasm-wrapper-cache-inl.h | 9 +- deps/v8/src/wasm/wasm-wrapper-cache.cc | 2 +- deps/v8/src/wasm/well-known-imports.cc | 17 + deps/v8/src/wasm/well-known-imports.h | 17 + deps/v8/src/wasm/wrappers.cc | 75 - deps/v8/test/benchmarks/cpp/benchmark-main.cc | 3 +- deps/v8/test/benchmarks/csuite/README.md | 43 - deps/v8/test/benchmarks/csuite/benchmark.py | 249 -- .../benchmarks/csuite/compare-baseline.py | 267 -- deps/v8/test/benchmarks/csuite/csuite.py | 174 - deps/v8/test/benchmarks/csuite/run-kraken.js | 63 - .../csuite/sunspider-standalone-driver.js | 75 - deps/v8/test/bigint/BUILD.gn | 2 + deps/v8/test/bigint/DEPS | 1 + deps/v8/test/bigint/bigint-shell.cc | 647 +++- deps/v8/test/cctest/BUILD.gn | 20 +- deps/v8/test/cctest/cctest.cc | 2 +- deps/v8/test/cctest/cctest.status | 40 +- .../cctest/compiler/test-code-generator.cc | 29 +- .../test-run-calls-to-external-references.cc | 6 + .../test-run-machops-select-loong64.cc | 250 -- .../cctest/compiler/test-run-native-calls.cc | 6 +- .../compiler/turboshaft-codegen-tester.h | 2 + deps/v8/test/cctest/heap/heap-tester.h | 4 +- deps/v8/test/cctest/heap/test-compaction.cc | 2 +- .../cctest/heap/test-concurrent-allocation.cc | 24 +- deps/v8/test/cctest/heap/test-heap.cc | 468 ++- deps/v8/test/cctest/heap/test-mark-compact.cc | 6 +- deps/v8/test/cctest/heap/test-spaces.cc | 36 +- .../test/cctest/heap/test-weak-references.cc | 50 +- deps/v8/test/cctest/test-accessors.cc | 25 +- deps/v8/test/cctest/test-api-array-buffer.cc | 57 +- deps/v8/test/cctest/test-api-incumbent.cc | 16 +- deps/v8/test/cctest/test-api-interceptors.cc | 405 +- deps/v8/test/cctest/test-api-stack-traces.cc | 547 ++- deps/v8/test/cctest/test-api-typed-array.cc | 22 +- deps/v8/test/cctest/test-api.cc | 562 ++- deps/v8/test/cctest/test-api.h | 24 +- .../test/cctest/test-code-stub-assembler.cc | 36 +- deps/v8/test/cctest/test-cpu-profiler.cc | 72 +- deps/v8/test/cctest/test-debug-helper.cc | 31 +- deps/v8/test/cctest/test-debug.cc | 219 +- deps/v8/test/cctest/test-descriptor-array.cc | 4 +- deps/v8/test/cctest/test-heap-profiler.cc | 214 +- .../test-ignition-statistics-extension.cc | 130 - deps/v8/test/cctest/test-sampler-api.cc | 24 +- deps/v8/test/cctest/test-serialize.cc | 8 +- deps/v8/test/cctest/test-shared-strings.cc | 45 +- .../test/cctest/test-stack-unwinding-win64.cc | 2 +- .../test-swiss-name-dictionary-infra.cc | 2 +- deps/v8/test/cctest/test-trace-event.cc | 84 +- .../test-unscopables-hidden-prototype.cc | 2 +- deps/v8/test/cctest/test-usecounters.cc | 51 +- deps/v8/test/cctest/test-verifiers.cc | 34 +- deps/v8/test/cctest/torque/test-torque.cc | 172 +- .../v8/test/cctest/wasm/test-backing-store.cc | 7 +- .../cctest/wasm/test-compilation-cache.cc | 43 +- deps/v8/test/cctest/wasm/test-gc.cc | 35 +- deps/v8/test/cctest/wasm/test-grow-memory.cc | 8 +- .../cctest/wasm/test-liftoff-inspection.cc | 2 +- deps/v8/test/cctest/wasm/test-run-wasm-64.cc | 53 +- .../test/cctest/wasm/test-run-wasm-atomics.cc | 6 +- .../cctest/wasm/test-run-wasm-atomics64.cc | 6 +- deps/v8/test/cctest/wasm/test-run-wasm-f16.cc | 99 +- .../cctest/wasm/test-run-wasm-memory64.cc | 2 +- .../test/cctest/wasm/test-run-wasm-module.cc | 3 +- .../cctest/wasm/test-run-wasm-relaxed-simd.cc | 81 +- .../cctest/wasm/test-run-wasm-simd-liftoff.cc | 43 +- .../v8/test/cctest/wasm/test-run-wasm-simd.cc | 1086 ++++-- .../cctest/wasm/test-run-wasm-wrappers.cc | 4 +- deps/v8/test/cctest/wasm/test-run-wasm.cc | 85 +- .../cctest/wasm/test-streaming-compilation.cc | 27 +- .../test/cctest/wasm/test-wasm-breakpoints.cc | 25 +- deps/v8/test/cctest/wasm/test-wasm-metrics.cc | 55 +- .../cctest/wasm/test-wasm-serialization.cc | 33 +- .../cctest/wasm/test-wasm-shared-engine.cc | 145 +- deps/v8/test/cctest/wasm/test-wasm-stack.cc | 2 +- .../cctest/wasm/test-wasm-trap-position.cc | 2 +- deps/v8/test/cctest/wasm/wasm-simd-utils.cc | 159 +- deps/v8/test/cctest/wasm/wasm-simd-utils.h | 5 + deps/v8/test/common/wasm/fuzzer-common.cc | 20 +- deps/v8/test/common/wasm/wasm-macro-gen.h | 22 +- .../v8/test/common/wasm/wasm-module-runner.cc | 2 +- deps/v8/test/common/wasm/wasm-run-utils.cc | 103 +- deps/v8/test/common/wasm/wasm-run-utils.h | 59 +- .../regress-prepare-break-while-recompile.js | 11 +- deps/v8/test/debugger/debugger.status | 3 + .../debugger/regress/regress-483851884.js | 30 + .../debugger/regress/regress-485683107.js | 17 + .../debugger/regress/regress-486383560.js | 10 + .../debugger/regress/regress-488130830.js | 9 + deps/v8/test/filecheck/filecheck.status | 22 + .../js-wasm-wrapper-inlining-eager-deopt.js | 156 + .../js-wasm-wrapper-inlining-lazy-deopt.js | 3 +- .../js-wasm-wrapper-inlining-type-combos.js | 395 ++ .../test/filecheck/wasm-deopt-with-import.js | 43 + ...n-js-inlining-turboshaft-stacktrace-api.js | 28 + .../wasm-in-js-inlining-turboshaft.js | 939 +++++ .../wasm-turbolev-inlined-wrapper.js | 9 +- .../filecheck/wasm/crash/regress-481074858.js | 220 ++ .../turbofan-extern-convert-any-dynamic.js | 76 + .../turbofan-extern-convert-any-static.js | 26 + deps/v8/test/fuzzer/fuzzer-support.cc | 2 +- deps/v8/test/fuzzer/fuzzer.status | 8 + deps/v8/test/fuzzer/inspector-fuzzer.cc | 10 +- .../interpreter/interpreter-fuzzer-common.cc | 7 +- deps/v8/test/fuzzer/wasm/streaming.cc | 15 +- deps/v8/test/inspector/BUILD.gn | 2 + ...ontext-during-log-error-stack-expected.txt | 9 + .../destroy-context-during-log-error-stack.js | 28 + .../regress-crbug-503553614-expected.txt | 4 + .../debugger/regress-crbug-503553614.js | 38 + ...point-by-url-in-broken-script-expected.txt | 21 + .../set-breakpoint-by-url-in-broken-script.js | 20 + .../set-variable-value-oob-expected.txt | 5 + .../debugger/set-variable-value-oob.js | 53 + .../debugger/wasm-gc-anyref-expected.txt | 20 +- .../test/inspector/debugger/wasm-gc-anyref.js | 14 +- .../debugger/wasm-gc-breakpoints-expected.txt | 2 +- .../inspector/debugger/wasm-gc-breakpoints.js | 2 +- .../wasm-gc-multi-module-expected.txt | 8 +- .../debugger/wasm-gc-multi-module.js | 4 +- .../debugger/wasm-jspi-async-stack.js | 3 +- .../debugger/wasm-scope-info-expected.txt | 45 +- .../inspector/debugger/wasm-scope-info.js | 28 +- deps/v8/test/inspector/devtools-session.cc | 66 + deps/v8/test/inspector/devtools-session.h | 65 + deps/v8/test/inspector/frontend-channel.h | 38 +- deps/v8/test/inspector/inspector-test.cc | 14 +- deps/v8/test/inspector/isolate-data.cc | 91 +- deps/v8/test/inspector/isolate-data.h | 28 +- .../regress-crbug-486927780-expected.txt | 1 + .../regress/regress-crbug-486927780.js | 25 + .../regress-crbug-488754138-expected.txt | 3 + .../regress/regress-crbug-488754138.js | 29 + .../regress-crbug-502724368-expected.txt | 22 + .../regress/regress-crbug-502724368.js | 40 + .../regress-crbug-516311623-expected.txt | 24 + .../regress/regress-crbug-516311623.js | 72 + .../runtime/command-line-api-expected.txt | 56 + .../inspector/runtime/command-line-api.js | 16 + .../runtime/evaluate-async-expected.txt | 4 +- .../runtime/get-properties-expected.txt | 11 - .../test/inspector/runtime/get-properties.js | 14 +- .../runtime/regress-488790217-expected.txt | 396 ++ .../inspector/runtime/regress-488790217.js | 39 + .../runtime/regress-517981277-expected.txt | 3 + .../inspector/runtime/regress-517981277.js | 38 + .../test/intl/date-format/check-nu-option.js | 2 +- .../date-format/check-numbering-system.js | 2 +- .../date-format/en-format-range-to-parts.js | 4 +- deps/v8/test/intl/date-format/format-range.js | 24 +- .../property-override-date-style.js | 2 +- .../property-override-date-time-style.js | 2 +- .../property-override-time-style.js | 2 +- .../intl/date-format/property-override.js | 2 +- .../intl/number-format/check-nu-option.js | 2 +- .../number-format/check-numbering-system.js | 2 +- .../intl/number-format/comma-compat-off.js | 22 - .../intl/number-format/comma-compat-on.js | 22 - .../intl/number-format/italian-compat-off.js | 15 - .../intl/number-format/italian-compat-on.js | 15 - deps/v8/test/intl/regress-7481.js | 2 +- deps/v8/test/intl/regress-9912.js | 6 +- .../check-numbering-system.js | 2 +- .../segment-iterator-ownPropertyDescriptor.js | 2 +- .../test/js-perf-test/BigInt/bigint-util.js | 2 +- deps/v8/test/js-perf-test/JSTests5.json | 2 +- .../TurboFan/wasm-inlining-loop-array.js | 2 +- .../message/fail/iterator-zip-return-error.js | 16 + .../fail/iterator-zip-return-error.out | 7 + .../test/message/fail/regress-tdz-closure.js | 12 + .../test/message/fail/regress-tdz-closure.out | 10 + .../js-wasm-wrapper-inlining-turbolev-32.js | 1 + .../js-wasm-wrapper-inlining-turbolev-32.out | 52 +- .../js-wasm-wrapper-inlining-turbolev-64.js | 1 + .../js-wasm-wrapper-inlining-turbolev-64.out | 70 +- deps/v8/test/message/message.status | 12 +- .../wasm-compilation-hints-inlining.out | 1 - .../message/wasm-in-js-inlining-turboshaft.js | 288 -- .../wasm-in-js-inlining-turboshaft.out | 329 -- deps/v8/test/message/wasm-inlining-into-js.js | 2 +- .../v8/test/message/wasm-inlining-into-js.out | 16 +- .../v8/test/message/wasm-recognize-imports.js | 8 +- deps/v8/test/mjsunit/BUILD.gn | 1 + .../mjsunit/additive-safe-int-feedback.js | 39 +- .../test/mjsunit/arbitrary-length-varargs.js | 126 + .../test/mjsunit/array-flat-elements-kind.js | 48 + deps/v8/test/mjsunit/array-sort-inline.js | 753 ++++ deps/v8/test/mjsunit/array-sort-stability.js | 56 + .../v8/test/mjsunit/call-intrinsic-fuzzing.js | 11 + .../compiler/bigint-add-no-deopt-loop.js | 5 +- .../mjsunit/compiler/fast-api-calls-wasm.js | 2 +- .../v8/test/mjsunit/compiler/float16-array.js | 29 + deps/v8/test/mjsunit/compiler/no-fma.js | 25 + .../mjsunit/compiler/regress-488078904.js | 21 + .../mjsunit/compiler/regress-488925413.js | 28 + .../mjsunit/compiler/regress-498818400.js | 31 + .../mjsunit/compiler/regress-499319121.js | 17 + .../mjsunit/compiler/regress-504073873.js | 18 + .../mjsunit/compiler/regress-505823721.js | 64 + .../mjsunit/d8-builtins-not-constructors.js | 21 + deps/v8/test/mjsunit/d8/cwd/working_dir.js | 18 + .../mjsunit/d8/cwd/working_dir_helper.js.skip | 5 + .../mjsunit/d8/cwd/working_dir_test.js.skip | 7 + deps/v8/test/mjsunit/d8/d8-realm-onerror.js | 26 + .../mjsunit/d8/d8-worker-onerror-arguments.js | 52 + .../mjsunit/d8/d8-worker-onerror-exception.js | 32 + .../d8/d8-worker-onerror-settimeout.js | 28 + deps/v8/test/mjsunit/d8/d8-worker-onerror.js | 32 + deps/v8/test/mjsunit/d8/files/exists.js | 12 + deps/v8/test/mjsunit/d8/module-bundle-1.js | 16 + deps/v8/test/mjsunit/d8/module-bundle-2.js | 16 + .../d8/module-bundle-dynamic-import-https.js | 17 + deps/v8/test/mjsunit/d8/regress-503488299.js | 8 + deps/v8/test/mjsunit/d8/script-bundle.js | 15 + deps/v8/test/mjsunit/d8_trace.js | 22 + .../mjsunit/ensure-growing-store-learns.js | 7 +- deps/v8/test/mjsunit/es6/big-weakmap.js | 4 +- .../mjsunit/es6/block-eval-var-over-let.js | 2 +- ...of-array-iterator-optimization-baseline.js | 38 +- ...of-array-iterator-optimization-ignition.js | 32 +- ...ization-maglev-eager-check-missing-done.js | 69 + ...terator-optimization-maglev-eager-check.js | 66 + ...tor-optimization-maglev-eager-next-call.js | 59 + ...r-optimization-maglev-eager-value-check.js | 90 + ...iterator-optimization-maglev-lazy-check.js | 64 + ...ator-optimization-maglev-lazy-next-call.js | 52 + ...or-optimization-maglev-lazy-value-check.js | 64 + ...r-of-array-iterator-optimization-maglev.js | 40 +- ...of-array-iterator-optimization-turbofan.js | 40 +- .../es6/for-of-iterator-protocol-integrity.js | 108 + .../mjsunit/es6/reflect-prevent-extensions.js | 2 +- .../es6/sloppy-restrictive-block-function.js | 2 +- .../test/mjsunit/es6/weak-map-chain-linear.js | 34 + .../es6/weak-map-chain-nested-linear.js | 61 + deps/v8/test/mjsunit/es8/async-await-basic.js | 2 +- .../harmony/async-from-sync-iterator.js | 4 +- .../mjsunit/harmony/async-generators-basic.js | 2 +- .../mjsunit/harmony/iterator-zip-keyed.js | 247 ++ deps/v8/test/mjsunit/harmony/iterator-zip.js | 205 ++ deps/v8/test/mjsunit/harmony/map-groupby.js | 2 +- .../harmony/modules-import-defer-asm.mjs | 22 + .../modules-import-defer-no-trigger.mjs | 29 +- ...efer-prototype-swap-for-in-that-throws.mjs | 30 + ...les-import-defer-prototype-swap-for-in.mjs | 23 + ...port-defer-super-property-set-exported.mjs | 25 + ...-defer-super-property-set-not-exported.mjs | 25 + .../mjsunit/harmony/modules-namespace-asm.mjs | 23 + .../harmony/regress/regress-499254994.js | 29 + .../harmony/regress/regress-499254996.mjs | 39 + deps/v8/test/mjsunit/homomorphic-array-smi.js | 59 + deps/v8/test/mjsunit/homomorphic-ic.js | 43 + deps/v8/test/mjsunit/iterable-foreach.js | 293 +- deps/v8/test/mjsunit/iterator-join.js | 408 ++ deps/v8/test/mjsunit/json-simd-strings.js | 136 + deps/v8/test/mjsunit/linecontinuation.js | 2 +- .../mjsunit/maglev/array-push-int32-phi.js | 33 + .../mjsunit/maglev/boolean-constructor.js | 23 + .../maglev/context-inverted-generator.js | 28 + .../maglev/context-inverted-generator2.js | 30 + .../test/mjsunit/maglev/maglev-508811474.js | 47 + deps/v8/test/mjsunit/maglev/math-round.js | 1 + deps/v8/test/mjsunit/maglev/reflect-apply.js | 72 + deps/v8/test/mjsunit/maglev/reflect-get.js | 42 + deps/v8/test/mjsunit/maglev/reflect-has.js | 54 + .../test/mjsunit/maglev/regress-470566252.js | 58 + .../test/mjsunit/maglev/regress-482545639.js | 18 + .../test/mjsunit/maglev/regress-482810539.js | 25 + .../test/mjsunit/maglev/regress-483423907.js | 24 + .../test/mjsunit/maglev/regress-484393248.js | 33 + .../test/mjsunit/maglev/regress-484911060.js | 16 + .../test/mjsunit/maglev/regress-485843940.js | 17 + .../test/mjsunit/maglev/regress-486530209.js | 26 + .../test/mjsunit/maglev/regress-489362238.js | 21 + .../test/mjsunit/maglev/regress-489369253.js | 25 + .../test/mjsunit/maglev/regress-490353576.js | 21 + .../test/mjsunit/maglev/regress-492245079.js | 30 + .../test/mjsunit/maglev/regress-494492520.js | 23 + .../test/mjsunit/maglev/regress-495041650.js | 26 + .../test/mjsunit/maglev/regress-495751197.js | 47 + .../test/mjsunit/maglev/regress-495888361.js | 26 + .../test/mjsunit/maglev/regress-495923720.js | 15 + .../test/mjsunit/maglev/regress-496074718.js | 27 + .../test/mjsunit/maglev/regress-496272034.js | 28 + .../test/mjsunit/maglev/regress-496627235.js | 24 + .../test/mjsunit/maglev/regress-497112471.js | 27 + .../test/mjsunit/maglev/regress-497831280.js | 25 + .../test/mjsunit/maglev/regress-498199197.js | 31 + .../mjsunit/maglev/regress-498816446-1.js | 27 + .../mjsunit/maglev/regress-498816446-2.js | 44 + .../mjsunit/maglev/regress-498816446-3.js | 27 + .../test/mjsunit/maglev/regress-499752800.js | 22 + .../test/mjsunit/maglev/regress-500174840.js | 19 + .../test/mjsunit/maglev/regress-500177421.js | 21 + .../test/mjsunit/maglev/regress-500193083.js | 34 + .../test/mjsunit/maglev/regress-500507435.js | 30 + .../test/mjsunit/maglev/regress-500774816.js | 24 + .../test/mjsunit/maglev/regress-501676158.js | 24 + .../test/mjsunit/maglev/regress-503197484.js | 17 + .../test/mjsunit/maglev/regress-503977642.js | 30 + .../mjsunit/maglev/regress-505413738-1.js | 13 + .../mjsunit/maglev/regress-505413738-2.js | 17 + .../test/mjsunit/maglev/regress-513350759.js | 37 + .../test/mjsunit/maglev/regress-523884658.js | 82 + .../maglev/regress/regress-489605205.js | 29 + .../mjsunit/maglev/string-indexof-includes.js | 54 + .../test/mjsunit/maglev/string-substring.js | 51 + .../maglev/uint8-clamped-store-undefined.js | 28 + .../v8/test/mjsunit/maglev/unused-loop-phi.js | 25 + .../v8/test/mjsunit/math-sum-precise/basic.js | 3 + .../test/mjsunit/math-sum-precise/closing.js | 26 + .../v8/test/mjsunit/math-sum-precise/holey.js | 15 + .../test/mjsunit/math-sum-precise/holey2.js | 33 + .../math-sum-precise/regress-494013010.js | 14 + .../regress-sumPrecise-iterator.js | 60 + .../set-iterator-clear-on-error.js | 28 + .../mjsunit/math-sum-precise/set-regress.js | 15 + .../mjsunit/math-sum-precise/set-regress2.js | 11 + deps/v8/test/mjsunit/mjsunit.status | 349 +- deps/v8/test/mjsunit/modules-eval-await.mjs | 9 + .../modules-namespace-super-access-tdz.mjs | 17 + .../modules-namespace-super-property-set.mjs | 17 + ...-namespace-super-set-tdz-with-accessor.mjs | 23 + ...les-skip-star-exports-indirect-cycle-a.mjs | 7 + ...les-skip-star-exports-indirect-cycle-b.mjs | 5 + ...les-skip-star-exports-indirect-cycle-c.mjs | 5 + ...les-skip-star-exports-indirect-cycle-d.mjs | 5 + .../modules-star-exports-indirect-cycle.mjs | 14 + .../test/mjsunit/object-prevent-extensions.js | 2 +- .../proto-seq-opt-object-entries.js | 4 +- .../opt-proto-seq/proto-seq-opt-spreading.js | 8 +- .../private_fields/test_private_fields.js | 145 + ...k-cross-realm-callback-report-exception.js | 30 + deps/v8/test/mjsunit/queue-microtask.js | 42 + .../test/mjsunit/random-bit-correlations.js | 4 +- deps/v8/test/mjsunit/regexp-fallback.js | 2 +- deps/v8/test/mjsunit/regress-478205262.js | 17 + deps/v8/test/mjsunit/regress-491935269.js | 24 + deps/v8/test/mjsunit/regress-493787228.js | 20 + deps/v8/test/mjsunit/regress-494876356.js | 20 + deps/v8/test/mjsunit/regress-507036687.js | 8 + .../regress-module-export-proto-helper.mjs | 5 + .../mjsunit/regress-module-export-proto.mjs | 29 + .../mjsunit/regress/asm/regress-490629397.js | 79 + .../mjsunit/regress/immutable-ab-regress.js | 85 + .../regress/redeclaration-error-types.js | 24 +- .../test/mjsunit/regress/regexp-489358153.js | 31 + .../test/mjsunit/regress/regress-1000635.js | 15 - .../test/mjsunit/regress/regress-1447383.js | 2 +- deps/v8/test/mjsunit/regress/regress-2443.js | 2 +- .../test/mjsunit/regress/regress-372298921.js | 2 +- .../test/mjsunit/regress/regress-435589244.js | 22 + .../test/mjsunit/regress/regress-447206453.js | 2 +- .../test/mjsunit/regress/regress-462795139.js | 26 + .../test/mjsunit/regress/regress-476509600.js | 9 + .../test/mjsunit/regress/regress-481519344.js | 21 + .../test/mjsunit/regress/regress-484904778.js | 15 + .../test/mjsunit/regress/regress-486655252.js | 17 + .../mjsunit/regress/regress-486945364-1.js | 32 + .../test/mjsunit/regress/regress-486945364.js | 39 + .../test/mjsunit/regress/regress-487468464.js | 15 + .../test/mjsunit/regress/regress-487857171.js | 17 + .../test/mjsunit/regress/regress-488042855.js | 19 + .../test/mjsunit/regress/regress-489356185.js | 26 + .../test/mjsunit/regress/regress-489941769.js | 16 + .../test/mjsunit/regress/regress-490446682.js | 11 + .../test/mjsunit/regress/regress-490485402.js | 32 + .../test/mjsunit/regress/regress-490515529.js | 23 + .../test/mjsunit/regress/regress-490640045.js | 33 + .../test/mjsunit/regress/regress-491053452.js | 18 + .../test/mjsunit/regress/regress-491461591.js | 16 + .../test/mjsunit/regress/regress-491881374.js | 70 + .../test/mjsunit/regress/regress-492014648.js | 29 + .../test/mjsunit/regress/regress-493176399.js | 23 + .../test/mjsunit/regress/regress-493269623.js | 12 + .../mjsunit/regress/regress-493591676.mjs | 5 + .../test/mjsunit/regress/regress-493787222.js | 17 + .../test/mjsunit/regress/regress-494388373.js | 12 + .../test/mjsunit/regress/regress-494583765.js | 7 + .../test/mjsunit/regress/regress-494690599.js | 15 + .../mjsunit/regress/regress-495503057.mjs | 5 + .../test/mjsunit/regress/regress-495503781.js | 19 + .../test/mjsunit/regress/regress-498010834.js | 37 + .../mjsunit/regress/regress-498089319-2.js | 28 + .../test/mjsunit/regress/regress-498089319.js | 38 + .../test/mjsunit/regress/regress-498464176.js | 17 + .../test/mjsunit/regress/regress-498904299.js | 18 + .../test/mjsunit/regress/regress-499260582.js | 20 + .../test/mjsunit/regress/regress-499323105.js | 22 + .../mjsunit/regress/regress-499527555-2.js | 47 + .../test/mjsunit/regress/regress-499527555.js | 66 + .../test/mjsunit/regress/regress-499659062.js | 28 + .../test/mjsunit/regress/regress-499667401.js | 44 + .../test/mjsunit/regress/regress-499672315.js | 23 + .../test/mjsunit/regress/regress-499721612.js | 10 + .../test/mjsunit/regress/regress-500174491.js | 9 + .../regress/regress-501224234-ignition.js | 44 + .../regress/regress-501224234-maglev.js | 70 + .../regress/regress-501224234-minimized.js | 11 + .../regress/regress-501224234-turbofan.js | 59 + .../test/mjsunit/regress/regress-501464526.js | 17 + .../mjsunit/regress/regress-501749462-ic.js | 24 + .../regress/regress-501749462-maglev.js | 23 + .../test/mjsunit/regress/regress-501749462.js | 23 + .../test/mjsunit/regress/regress-502244656.js | 18 + .../test/mjsunit/regress/regress-502439789.js | 15 + .../test/mjsunit/regress/regress-503097371.js | 7 + .../test/mjsunit/regress/regress-503634281.js | 28 + .../test/mjsunit/regress/regress-504490097.js | 36 + .../test/mjsunit/regress/regress-505101417.js | 11 + .../test/mjsunit/regress/regress-505116710.js | 12 + .../test/mjsunit/regress/regress-505481956.js | 36 + .../test/mjsunit/regress/regress-505551322.js | 73 + .../test/mjsunit/regress/regress-506617613.js | 23 + .../test/mjsunit/regress/regress-506855825.js | 11 + .../test/mjsunit/regress/regress-507671690.js | 21 + .../mjsunit/regress/regress-509268941-2.js | 50 + .../test/mjsunit/regress/regress-509312809.js | 18 + .../test/mjsunit/regress/regress-513936340.js | 29 + .../test/mjsunit/regress/regress-522126182.js | 17 + .../test/mjsunit/regress/regress-7558019.js | 16 + .../v8/test/mjsunit/regress/regress-786573.js | 2 +- .../regress/regress-crbug-335704358.js | 53 - .../mjsunit/regress/regress-crbug-42213031.js | 26 - .../regress/regress-crbug-488366773.js | 14 + .../regress/regress-crbug-488426618.js | 20 + .../regress/regress-crbug-489893167.js | 20 + .../regress/regress-crbug-490058830.js | 20 + .../regress/regress-crbug-502439789.js | 19 + .../regress/regress-crbug-502832780.js | 24 + .../regress/regress-crbug-502923583.js | 19 + .../regress/regress-crbug-502944996-b.js | 52 + .../regress/regress-crbug-502944996.js | 36 + .../regress/regress-crbug-503098806.js | 37 + .../regress/regress-crbug-503180648.js | 48 + .../regress/regress-crbug-503557995-b.js | 61 + .../regress/regress-crbug-503557995.js | 132 + .../regress/regress-crbug-503615221.js | 30 + .../regress/regress-crbug-503622403.js | 26 + .../regress/regress-crbug-504070398.js | 26 + .../regress/regress-crbug-506689381.js | 20 + .../mjsunit/regress/regress-crbug-596394.js | 2 +- .../mjsunit/regress/regress-crbug-897404.js | 2 +- .../mjsunit/regress/regress-crbug-909614.js | 8 +- .../regress/regress-temporal-zoneinfo.js | 11 + .../test/mjsunit/regress/regress-v8-12671.js | 14 +- .../regress/wasm/i32-lowering-inlining.js | 2 +- .../regress/wasm/inline-call-to-reexport.js | 3 +- .../mjsunit/regress/wasm/regress-1010272.js | 2 - .../mjsunit/regress/wasm/regress-1029642.js | 6 - .../mjsunit/regress/wasm/regress-1045225.js | 2 - .../mjsunit/regress/wasm/regress-1045737.js | 2 - .../mjsunit/regress/wasm/regress-1046472.js | 2 - .../mjsunit/regress/wasm/regress-1048241.js | 2 - .../mjsunit/regress/wasm/regress-1074586-b.js | 2 - .../mjsunit/regress/wasm/regress-1074586.js | 2 - .../mjsunit/regress/wasm/regress-1075953.js | 2 - .../mjsunit/regress/wasm/regress-1079449.js | 2 - .../mjsunit/regress/wasm/regress-10898.js | 2 - .../mjsunit/regress/wasm/regress-1125951.js | 2 +- .../mjsunit/regress/wasm/regress-1132461.js | 2 - .../mjsunit/regress/wasm/regress-1140549.js | 2 - .../mjsunit/regress/wasm/regress-1145135.js | 2 - .../mjsunit/regress/wasm/regress-1161654.js | 4 +- .../mjsunit/regress/wasm/regress-1161954.js | 2 - .../mjsunit/regress/wasm/regress-1165966.js | 2 - .../mjsunit/regress/wasm/regress-1168116.js | 2 - .../mjsunit/regress/wasm/regress-1171788.js | 2 - .../mjsunit/regress/wasm/regress-1179025.js | 2 - .../mjsunit/regress/wasm/regress-1179065.js | 2 +- .../mjsunit/regress/wasm/regress-1179182.js | 2 - .../mjsunit/regress/wasm/regress-11809.js | 3 +- .../mjsunit/regress/wasm/regress-1187831.js | 2 - .../mjsunit/regress/wasm/regress-1196837.js | 2 - .../mjsunit/regress/wasm/regress-1197393.js | 2 - .../mjsunit/regress/wasm/regress-1199662.js | 2 - .../mjsunit/regress/wasm/regress-1202736.js | 2 - .../mjsunit/regress/wasm/regress-1220855.js | 2 - .../mjsunit/regress/wasm/regress-12270.js | 2 - .../mjsunit/regress/wasm/regress-1227351.js | 2 - .../mjsunit/regress/wasm/regress-1228720.js | 2 - .../mjsunit/regress/wasm/regress-1236958.js | 2 +- .../mjsunit/regress/wasm/regress-1237024.js | 2 +- .../mjsunit/regress/wasm/regress-1239954.js | 2 +- .../mjsunit/regress/wasm/regress-1248024.js | 2 +- .../mjsunit/regress/wasm/regress-1251465.js | 2 - .../mjsunit/regress/wasm/regress-1255354.js | 3 +- .../mjsunit/regress/wasm/regress-12624.js | 2 - .../mjsunit/regress/wasm/regress-1264462.js | 2 - .../mjsunit/regress/wasm/regress-12874.js | 2 +- .../mjsunit/regress/wasm/regress-1294384.js | 2 - .../mjsunit/regress/wasm/regress-12945.js | 8 +- .../mjsunit/regress/wasm/regress-1296876.js | 2 - .../mjsunit/regress/wasm/regress-1299183.js | 2 - .../mjsunit/regress/wasm/regress-13061.js | 2 - .../mjsunit/regress/wasm/regress-1308333.js | 2 - .../mjsunit/regress/wasm/regress-1339153.js | 2 - .../mjsunit/regress/wasm/regress-13700.js | 2 - .../mjsunit/regress/wasm/regress-1374535.js | 2 +- .../mjsunit/regress/wasm/regress-1380646.js | 2 - .../mjsunit/regress/wasm/regress-13939.js | 2 - .../mjsunit/regress/wasm/regress-13946.js | 2 +- .../mjsunit/regress/wasm/regress-13956.js | 2 +- .../mjsunit/regress/wasm/regress-1408337.js | 2 - .../mjsunit/regress/wasm/regress-14113.js | 2 - .../mjsunit/regress/wasm/regress-14116.js | 2 - .../mjsunit/regress/wasm/regress-14118.js | 2 - .../mjsunit/regress/wasm/regress-14167.js | 10 +- .../mjsunit/regress/wasm/regress-14171.js | 2 - .../mjsunit/regress/wasm/regress-14270.js | 2 +- .../mjsunit/regress/wasm/regress-14356.js | 2 - .../mjsunit/regress/wasm/regress-1447367.js | 2 +- .../mjsunit/regress/wasm/regress-1458941.js | 4 +- .../mjsunit/regress/wasm/regress-14600.js | 11 +- .../mjsunit/regress/wasm/regress-14689.js | 2 - .../mjsunit/regress/wasm/regress-14695.js | 4 +- .../mjsunit/regress/wasm/regress-14700.js | 2 +- .../mjsunit/regress/wasm/regress-1478848.js | 4 +- .../mjsunit/regress/wasm/regress-1478913.js | 2 - .../mjsunit/regress/wasm/regress-1479926.js | 14 +- .../mjsunit/regress/wasm/regress-1480117.js | 2 - .../mjsunit/regress/wasm/regress-1484393.js | 2 - .../mjsunit/regress/wasm/regress-1486237.js | 4 +- .../mjsunit/regress/wasm/regress-1487077.js | 2 - .../mjsunit/regress/wasm/regress-1490847-2.js | 6 +- .../mjsunit/regress/wasm/regress-1490847.js | 2 +- .../mjsunit/regress/wasm/regress-1491415.js | 7 +- .../mjsunit/regress/wasm/regress-1492772.js | 2 - .../mjsunit/regress/wasm/regress-1497018.js | 2 - .../mjsunit/regress/wasm/regress-1502837.js | 2 - .../mjsunit/regress/wasm/regress-1507743.js | 4 +- .../mjsunit/regress/wasm/regress-1507779.js | 2 +- .../mjsunit/regress/wasm/regress-1508999.js | 2 - .../mjsunit/regress/wasm/regress-1514072.js | 2 +- .../mjsunit/regress/wasm/regress-1517219.js | 2 - .../mjsunit/regress/wasm/regress-1517243.js | 4 +- .../mjsunit/regress/wasm/regress-1519091.js | 2 - .../mjsunit/regress/wasm/regress-1520362.js | 2 +- .../mjsunit/regress/wasm/regress-1521371.js | 4 +- .../mjsunit/regress/wasm/regress-1523313.js | 2 - .../mjsunit/regress/wasm/regress-1523316.js | 4 +- .../mjsunit/regress/wasm/regress-1523407.js | 4 +- .../mjsunit/regress/wasm/regress-1523414.js | 2 +- .../mjsunit/regress/wasm/regress-324475066.js | 2 +- .../mjsunit/regress/wasm/regress-324690505.js | 4 +- .../mjsunit/regress/wasm/regress-324747822.js | 2 +- .../mjsunit/regress/wasm/regress-325756545.js | 8 +- .../mjsunit/regress/wasm/regress-326156493.js | 8 +- .../mjsunit/regress/wasm/regress-326260438.js | 4 +- .../mjsunit/regress/wasm/regress-326273468.js | 2 - .../mjsunit/regress/wasm/regress-326894018.js | 96 +- .../mjsunit/regress/wasm/regress-326904344.js | 6 +- .../mjsunit/regress/wasm/regress-327517308.js | 2 - .../mjsunit/regress/wasm/regress-327643791.js | 6 +- .../mjsunit/regress/wasm/regress-328499555.js | 9 +- .../mjsunit/regress/wasm/regress-329130358.js | 3 +- .../mjsunit/regress/wasm/regress-329464129.js | 2 - .../mjsunit/regress/wasm/regress-330580823.js | 5 +- .../mjsunit/regress/wasm/regress-330767273.js | 23 +- .../mjsunit/regress/wasm/regress-333457544.js | 2 - .../mjsunit/regress/wasm/regress-336007398.js | 2 +- .../mjsunit/regress/wasm/regress-336214779.js | 5 +- .../mjsunit/regress/wasm/regress-336358915.js | 5 - .../mjsunit/regress/wasm/regress-336852356.js | 2 +- .../mjsunit/regress/wasm/regress-342602616.js | 12 +- .../mjsunit/regress/wasm/regress-343035068.js | 2 +- .../mjsunit/regress/wasm/regress-343917751.js | 2 +- .../mjsunit/regress/wasm/regress-344014332.js | 2 +- .../mjsunit/regress/wasm/regress-346197738.js | 2 +- .../mjsunit/regress/wasm/regress-346505953.js | 2 +- .../mjsunit/regress/wasm/regress-347914831.js | 3 +- .../mjsunit/regress/wasm/regress-349402547.js | 2 - .../mjsunit/regress/wasm/regress-349640002.js | 3 +- .../mjsunit/regress/wasm/regress-350779988.js | 4 +- .../regress/wasm/regress-352720899-2.js | 3 +- .../mjsunit/regress/wasm/regress-353582136.js | 2 +- .../mjsunit/regress/wasm/regress-353913485.js | 4 +- .../mjsunit/regress/wasm/regress-360044696.js | 6 +- .../mjsunit/regress/wasm/regress-360052650.js | 4 +- .../mjsunit/regress/wasm/regress-360700873.js | 2 +- .../mjsunit/regress/wasm/regress-361123483.js | 2 - .../mjsunit/regress/wasm/regress-361611472.js | 2 +- .../mjsunit/regress/wasm/regress-361717714.js | 2 - .../mjsunit/regress/wasm/regress-361862737.js | 2 +- .../mjsunit/regress/wasm/regress-362539773.js | 3 +- .../mjsunit/regress/wasm/regress-363072477.js | 4 +- .../mjsunit/regress/wasm/regress-364312793.js | 5 +- .../mjsunit/regress/wasm/regress-364667545.js | 2 +- .../mjsunit/regress/wasm/regress-365376497.js | 2 - .../mjsunit/regress/wasm/regress-365802567.js | 15 +- .../mjsunit/regress/wasm/regress-368086282.js | 4 +- .../mjsunit/regress/wasm/regress-369533086.js | 2 - .../mjsunit/regress/wasm/regress-369652650.js | 3 +- .../mjsunit/regress/wasm/regress-372067240.js | 6 +- .../mjsunit/regress/wasm/regress-372261626.js | 2 +- .../mjsunit/regress/wasm/regress-373702823.js | 2 +- .../mjsunit/regress/wasm/regress-375270509.js | 2 +- .../mjsunit/regress/wasm/regress-377620832.js | 2 +- .../mjsunit/regress/wasm/regress-379414135.js | 2 +- .../mjsunit/regress/wasm/regress-380397544.js | 4 +- .../mjsunit/regress/wasm/regress-381696874.js | 6 +- .../mjsunit/regress/wasm/regress-381917890.js | 2 +- .../mjsunit/regress/wasm/regress-382291459.js | 10 +- .../mjsunit/regress/wasm/regress-382547695.js | 4 +- .../mjsunit/regress/wasm/regress-383356864.js | 4 +- .../mjsunit/regress/wasm/regress-384549252.js | 4 +- .../mjsunit/regress/wasm/regress-384974501.js | 8 +- .../mjsunit/regress/wasm/regress-385256127.js | 8 +- .../mjsunit/regress/wasm/regress-387055479.js | 2 +- .../mjsunit/regress/wasm/regress-390467420.js | 2 +- .../mjsunit/regress/wasm/regress-390675703.js | 4 +- .../mjsunit/regress/wasm/regress-391907159.js | 80 + .../mjsunit/regress/wasm/regress-392928805.js | 2 +- .../mjsunit/regress/wasm/regress-393632542.js | 11 +- .../mjsunit/regress/wasm/regress-399497254.js | 2 +- .../mjsunit/regress/wasm/regress-400852655.js | 5 +- .../mjsunit/regress/wasm/regress-40258436.js | 5 +- .../mjsunit/regress/wasm/regress-406043349.js | 2 - .../mjsunit/regress/wasm/regress-407298298.js | 2 - .../mjsunit/regress/wasm/regress-407797300.js | 2 +- .../mjsunit/regress/wasm/regress-408254017.js | 1 - .../mjsunit/regress/wasm/regress-413963387.js | 2 +- .../mjsunit/regress/wasm/regress-433984397.js | 4 +- .../mjsunit/regress/wasm/regress-434008619.js | 9 +- .../mjsunit/regress/wasm/regress-438770394.js | 2 +- .../mjsunit/regress/wasm/regress-445870128.js | 2 +- .../mjsunit/regress/wasm/regress-447613211.js | 2 +- .../mjsunit/regress/wasm/regress-451144692.js | 2 - .../mjsunit/regress/wasm/regress-452079540.js | 2 +- .../mjsunit/regress/wasm/regress-452541294.js | 2 +- .../mjsunit/regress/wasm/regress-454276076.js | 2 +- .../mjsunit/regress/wasm/regress-454363539.js | 2 +- .../mjsunit/regress/wasm/regress-455711115.js | 3 +- .../mjsunit/regress/wasm/regress-470127856.js | 7 +- .../mjsunit/regress/wasm/regress-471380636.js | 9 +- .../mjsunit/regress/wasm/regress-474491347.js | 7 +- .../mjsunit/regress/wasm/regress-482759504.js | 22 + .../mjsunit/regress/wasm/regress-483269968.js | 42 + .../mjsunit/regress/wasm/regress-483643012.js | 13 + .../mjsunit/regress/wasm/regress-484405356.js | 22 + .../mjsunit/regress/wasm/regress-484499097.js | 15 + .../mjsunit/regress/wasm/regress-487444465.js | 17 + .../mjsunit/regress/wasm/regress-487750545.js | 16 + .../mjsunit/regress/wasm/regress-488089242.js | 45 + .../mjsunit/regress/wasm/regress-488790214.js | 59 + .../mjsunit/regress/wasm/regress-488943662.js | 26 + .../mjsunit/regress/wasm/regress-489029655.js | 11 + .../mjsunit/regress/wasm/regress-489109716.js | 67 + .../mjsunit/regress/wasm/regress-489349562.js | 60 + .../mjsunit/regress/wasm/regress-490183533.js | 32 + .../mjsunit/regress/wasm/regress-490877756.js | 35 + .../mjsunit/regress/wasm/regress-490877757.js | 35 + .../mjsunit/regress/wasm/regress-490877758.js | 28 + .../mjsunit/regress/wasm/regress-490970052.js | 9 + .../mjsunit/regress/wasm/regress-491696923.js | 90 + .../mjsunit/regress/wasm/regress-493088266.js | 24 + .../mjsunit/regress/wasm/regress-493099941.js | 78 + .../mjsunit/regress/wasm/regress-493171989.js | 34 + .../mjsunit/regress/wasm/regress-493197128.js | 13 + .../mjsunit/regress/wasm/regress-493307331.js | 8 + .../mjsunit/regress/wasm/regress-493314948.js | 50 + .../mjsunit/regress/wasm/regress-493319628.js | 36 + .../mjsunit/regress/wasm/regress-493430818.js | 40 + .../mjsunit/regress/wasm/regress-493521637.js | 18 + .../mjsunit/regress/wasm/regress-493521807.js | 75 + .../mjsunit/regress/wasm/regress-493529579.js | 32 + .../mjsunit/regress/wasm/regress-493646648.js | 18 + .../mjsunit/regress/wasm/regress-493905761.js | 52 + .../mjsunit/regress/wasm/regress-495503265.js | 19 + .../mjsunit/regress/wasm/regress-496628168.js | 14 + .../mjsunit/regress/wasm/regress-497330272.js | 25 + .../mjsunit/regress/wasm/regress-497404188.js | 92 + .../mjsunit/regress/wasm/regress-498709150.js | 121 + .../mjsunit/regress/wasm/regress-498814570.js | 40 + .../mjsunit/regress/wasm/regress-498818401.js | 80 + .../mjsunit/regress/wasm/regress-499150024.js | 49 + .../mjsunit/regress/wasm/regress-499492236.js | 56 + .../mjsunit/regress/wasm/regress-500113958.js | 87 + .../mjsunit/regress/wasm/regress-500171779.js | 19 + .../mjsunit/regress/wasm/regress-500181839.js | 36 + .../mjsunit/regress/wasm/regress-500890918.js | 10 + .../mjsunit/regress/wasm/regress-501198834.js | 17 + .../mjsunit/regress/wasm/regress-502030575.js | 50 + .../mjsunit/regress/wasm/regress-502287689.js | 107 + .../mjsunit/regress/wasm/regress-502300817.js | 33 + .../mjsunit/regress/wasm/regress-502624513.js | 16 + .../mjsunit/regress/wasm/regress-504612573.js | 23 + .../mjsunit/regress/wasm/regress-504708686.js | 7 + .../mjsunit/regress/wasm/regress-504711585.js | 29 + .../mjsunit/regress/wasm/regress-504714846.js | 23 + .../mjsunit/regress/wasm/regress-504716006.js | 52 + .../mjsunit/regress/wasm/regress-505117973.js | 46 + .../mjsunit/regress/wasm/regress-505124865.js | 11 + .../mjsunit/regress/wasm/regress-505481948.js | 108 + .../mjsunit/regress/wasm/regress-505858818.js | 18 + .../regress/wasm/regress-509268941-1.js | 117 + .../mjsunit/regress/wasm/regress-509268941.js | 75 + .../mjsunit/regress/wasm/regress-863810.js | 2 +- .../test/mjsunit/regress/wasm/regress-9017.js | 2 - .../test/mjsunit/regress/wasm/regress-9759.js | 2 +- .../regress/wasm/regress-crbug-1002388.js | 4 +- .../regress/wasm/regress-crbug-1006631.js | 7 - .../regress/wasm/regress-crbug-1047368.js | 14 - .../regress/wasm/regress-crbug-1339321.js | 2 +- .../regress/wasm/regress-crbug-1463219.js | 8 - .../regress/wasm/regress-crbug-1463232.js | 14 +- .../regress/wasm/regress-crbug-1464604.js | 2 - .../regress/wasm/regress-crbug-1465386.js | 2 - .../regress/wasm/regress-crbug-1466312.js | 8 +- .../regress/wasm/regress-crbug-1491815.js | 2 - .../regress/wasm/regress-crbug-1520130.js | 2 - .../regress/wasm/regress-inlining-throw.js | 6 +- .../regress/wasm/regress-simd-391916477.js | 2 - .../regress/wasm/regress-simd-396460489.js | 2 +- .../regress/wasm/regress-simd-458024245.js | 2 +- .../regress/wasm/regress-simd-507671691.js | 24 + .../regress/wasm/regress-simd-508025392.js | 58 + .../regress-struct-set-into-unreachable.js | 10 +- .../mjsunit/regress/wasm/regress-v8-14471.js | 3 +- .../mjsunit/regress/wasm/regress-v8-14710.js | 2 +- .../wasm/wasm-typer-incompatible-ref-cast.js | 6 +- .../basic-hardware-watchpoints.js | 2 +- .../double-registers-double-watchpoint.js | 20 + .../hardware-watchpoints/double-registers.js | 19 + .../duplicate-watchpoint.js | 19 + .../hardware-watchpoints/regress-486705321.js | 9 + .../hardware-watchpoints/regress-496855012.js | 9 + .../sandbox/liftoff-wasmarray-i64-indexing.js | 6 +- .../test/mjsunit/sandbox/regress-488362583.js | 60 + .../test/mjsunit/sandbox/regress-488651088.js | 28 + .../test/mjsunit/sandbox/regress-488927521.js | 75 + .../test/mjsunit/sandbox/regress-490769268.js | 40 + .../test/mjsunit/sandbox/regress-496618662.js | 33 + .../test/mjsunit/sandbox/regress-496807861.js | 24 + .../test/mjsunit/sandbox/regress-499717570.js | 30 + .../test/mjsunit/sandbox/regress-501147587.js | 71 + .../test/mjsunit/sandbox/regress-502356099.js | 44 + .../mjsunit/sandbox/regress-getparameter.js | 54 + .../sandbox/regress/regress-392180065.js | 2 +- .../sandbox/regress/regress-454734141.js | 2 +- .../sandbox/regress/regress-469759459.js | 2 +- .../sandbox/regress/regress-496341820.js | 62 + .../sandbox/regress/regress-501115746.js | 74 + .../sandbox/regress/regress-501626906.js | 22 + .../sandbox/regress/regress-502337304.js | 76 + .../sandbox/wasm-table-wasmjsfunction.js | 5 +- .../mjsunit/sandbox/wasmfx-signature-check.js | 83 + .../shared-memory/regress-488754149.js | 30 + .../v8/test/mjsunit/string-external-cached.js | 4 +- .../mjsunit/tools/foozzie_arch_specific.js | 3 + .../tools/tickprocessor-test-large.log | 2 +- .../test/mjsunit/tools/v8-logviewer-args.mjs | 83 + .../phi-untagging-conversions-truncation.js | 12 +- .../mjsunit/turbolev/regress-479549166.js | 22 + .../mjsunit/turbolev/regress-482084211.js | 20 + .../mjsunit/turbolev/regress-484527367.js | 28 + .../mjsunit/turbolev/regress-485478594.js | 20 + .../mjsunit/turbolev/regress-485535276.js | 26 + .../mjsunit/turbolev/regress-487646536.js | 26 + .../mjsunit/turbolev/regress-488090094.js | 23 + .../mjsunit/turbolev/regress-488790215.js | 27 + .../mjsunit/turbolev/regress-489193276.js | 18 + .../mjsunit/turbolev/regress-489689984.js | 21 + .../mjsunit/turbolev/regress-490450922-1.js | 20 + .../mjsunit/turbolev/regress-490450922-2.js | 31 + .../mjsunit/turbolev/regress-490450922-3.js | 35 + .../mjsunit/turbolev/regress-491466705.js | 93 + .../mjsunit/turbolev/regress-492046462.js | 17 + .../mjsunit/turbolev/regress-493319584.js | 34 + .../mjsunit/turbolev/regress-493534950.js | 41 + .../mjsunit/turbolev/regress-494058284.js | 89 + .../mjsunit/turbolev/regress-498813012.js | 18 + .../mjsunit/turbolev/regress-499934837.js | 26 + .../mjsunit/turbolev/regress-503975738-1.js | 46 + .../mjsunit/turbolev/regress-503975738-2.js | 46 + .../mjsunit/turbolev/regress-505610970.js | 34 + .../mjsunit/turbolev/regress-506060820.js | 26 + .../super-try-catch-derived-constructor.js | 17 + .../mjsunit/turboshaft/regress-508347351.js | 18 + .../mjsunit/turboshaft/regress-527385397.js | 67 + .../typedarray-with-resizable-buffer.js | 119 + deps/v8/test/mjsunit/unicode-test.js | 4 +- .../mjsunit/wasm/array-bulk-operations.js | 20 +- .../test/mjsunit/wasm/array-copy-benchmark.js | 8 +- .../v8/test/mjsunit/wasm/array-copy-errors.js | 2 +- deps/v8/test/mjsunit/wasm/array-fill-gc.js | 2 +- .../mjsunit/wasm/array-init-from-segment.js | 16 +- deps/v8/test/mjsunit/wasm/bigint-opt.js | 2 +- .../mjsunit/wasm/call-indirect-null-check.js | 25 + deps/v8/test/mjsunit/wasm/call-ref.js | 18 +- deps/v8/test/mjsunit/wasm/call_indirect.js | 2 +- deps/v8/test/mjsunit/wasm/compact-imports.js | 168 + .../mjsunit/wasm/compile-time-builtins.js | 139 + .../wasm/compiled-module-serialization.js | 49 + .../wasm/custom-descriptors-boundary.js | 273 ++ .../wasm/custom-descriptors-inlining.js | 15 +- .../mjsunit/wasm/custom-descriptors-oom.js | 85 + .../wasm/deopt/deopt-many-params-tagged.js | 4 +- .../mjsunit/wasm/deopt/deopt-many-results.js | 2 +- .../deopt/deopt-untagged-parameters-s128.js | 2 +- .../wasm/deopt/deopt-untagged-parameters.js | 3 +- deps/v8/test/mjsunit/wasm/exceptions-gc.js | 4 +- .../wasm/exceptions-type-reflection.js | 54 - deps/v8/test/mjsunit/wasm/exnref-api.js | 4 +- deps/v8/test/mjsunit/wasm/exnref-global.js | 2 - deps/v8/test/mjsunit/wasm/exnref-rethrow.js | 4 +- deps/v8/test/mjsunit/wasm/exnref.js | 29 +- deps/v8/test/mjsunit/wasm/externref-table.js | 6 +- deps/v8/test/mjsunit/wasm/gc-casts-exnref.js | 2 +- .../v8/test/mjsunit/wasm/gc-casts-from-any.js | 7 +- deps/v8/test/mjsunit/wasm/gc-casts-invalid.js | 15 +- .../v8/test/mjsunit/wasm/gc-casts-subtypes.js | 21 +- .../mjsunit/wasm/gc-js-interop-helpers.js | 2 +- deps/v8/test/mjsunit/wasm/gc-nominal.js | 9 +- deps/v8/test/mjsunit/wasm/gc-null-traps.js | 4 +- .../mjsunit/wasm/gc-optimization-array-get.js | 5 +- deps/v8/test/mjsunit/wasm/gc-optimizations.js | 58 +- deps/v8/test/mjsunit/wasm/gc-ref-eq.js | 2 +- .../test/mjsunit/wasm/gc-typecheck-reducer.js | 2 - .../wasm/grow-huge-memory-resizable-buffer.js | 2 +- .../grow-memory-detaching-resizable-buffer.js | 2 - .../grow-memory-in-branch-resizable-buffer.js | 2 +- .../grow-memory-in-call-resizable-buffer.js | 2 +- .../grow-memory-in-loop-resizable-buffer.js | 2 +- .../wasm/grow-memory-resizable-buffer.js | 2 +- deps/v8/test/mjsunit/wasm/grow-memory.js | 21 + .../grow-shared-memory-resizable-buffer.js | 59 +- .../test/mjsunit/wasm/grow-shared-memory.js | 90 + deps/v8/test/mjsunit/wasm/growable-stacks.js | 2 +- deps/v8/test/mjsunit/wasm/half-shuffles.js | 2 - .../mjsunit/wasm/imported-strings-invalid.js | 18 +- .../mjsunit/wasm/imported-strings-utf8.js | 6 +- deps/v8/test/mjsunit/wasm/imported-strings.js | 2 +- .../wasm/indirect-call-non-zero-table.js | 4 +- deps/v8/test/mjsunit/wasm/indirect-calls.js | 4 +- deps/v8/test/mjsunit/wasm/indirect-tables.js | 11 +- .../v8/test/mjsunit/wasm/interleaved-loads.js | 1 - deps/v8/test/mjsunit/wasm/js-to-js.js | 24 +- .../mjsunit/wasm/js-wrapper-typechecks.js | 2 - deps/v8/test/mjsunit/wasm/jspi-export.js | 1 - .../test/mjsunit/wasm/jspi-generic-wrapper.js | 1 - deps/v8/test/mjsunit/wasm/jspi-no-stress.js | 5 +- deps/v8/test/mjsunit/wasm/jspi-notraps.js | 2 - deps/v8/test/mjsunit/wasm/jspi.js | 10 +- deps/v8/test/mjsunit/wasm/large-struct.js | 12 +- deps/v8/test/mjsunit/wasm/liftoff-debug.js | 2 +- deps/v8/test/mjsunit/wasm/load-immutable.js | 4 +- deps/v8/test/mjsunit/wasm/load-shift32.js | 79 + .../wasm/log-wasm-to-js-wrapper-callref.js | 32 +- .../wasm/log-wasm-to-js-wrapper-indirect.js | 29 +- deps/v8/test/mjsunit/wasm/loop-rotation.js | 2 +- deps/v8/test/mjsunit/wasm/loop-unrolling.js | 1 - .../test/mjsunit/wasm/memory-copy-inline.js | 2 - ...ble-buffer-array-concat-dictionary-mode.js | 1 - .../memory-resizable-buffer-array-concat.js | 1 - .../memory-resizable-buffer-array-filter.js | 1 - ...esizable-buffer-array-flat-flatmap-from.js | 1 - ...izable-buffer-array-flat-grows-detaches.js | 1 - ...ble-buffer-array-flatmap-grows-detaches.js | 1 - ...y-resizable-buffer-array-foreach-reduce.js | 1 - ...izable-buffer-array-from-grows-detaches.js | 1 - ...memory-resizable-buffer-array-pop-shift.js | 1 - ...izable-buffer-array-push-unshift-splice.js | 1 - .../memory-resizable-buffer-array-slice.js | 1 - .../wasm/memory-resizable-buffer-errors.js | 2 - .../memory-toresizable-max-byte-length.js | 2 - .../wasm/memory-toresizable-tofixedlength.js | 1 - deps/v8/test/mjsunit/wasm/memory64.js | 52 + deps/v8/test/mjsunit/wasm/mixed-eh-invalid.js | 2 - .../mjsunit/wasm/prototype-setup-builder.js | 19 +- deps/v8/test/mjsunit/wasm/quarter-shuffles.js | 268 ++ .../v8/test/mjsunit/wasm/recognize-imports.js | 2 +- .../mjsunit/wasm/redundant-shuffle-lanes.js | 731 +++- .../test/mjsunit/wasm/ref-cast-js-function.js | 4 +- .../mjsunit/wasm/reference-globals-import.js | 28 +- .../v8/test/mjsunit/wasm/reference-globals.js | 12 +- .../wasm/reference-table-js-interop.js | 6 +- deps/v8/test/mjsunit/wasm/reference-tables.js | 22 +- .../v8/test/mjsunit/wasm/regress-367818758.js | 2 +- .../v8/test/mjsunit/wasm/regress-450652935.js | 3 +- .../v8/test/mjsunit/wasm/regress-474141354.js | 1 - .../v8/test/mjsunit/wasm/regress-488803413.js | 2 - .../v8/test/mjsunit/wasm/regress-496645739.js | 58 + .../v8/test/mjsunit/wasm/regress-497667917.js | 44 + .../v8/test/mjsunit/wasm/regress-498482620.js | 65 + .../v8/test/mjsunit/wasm/regress-499719427.js | 50 + .../v8/test/mjsunit/wasm/regress-522454846.js | 44 + .../wasm/regress-dataview-immutable.js | 38 + .../wasm/regress-wasmfx-exact-types.js | 102 + deps/v8/test/mjsunit/wasm/resume-throw.js | 117 +- ...tructions.js => acq-rel-load-and-store.js} | 0 .../acq-rel-rmw-operations.js | 246 ++ .../array-atomic-rmw-load-elimination.js | 2 +- .../wasm/shared-everything/array-new-elem.js | 2 +- .../shared-everything/atomic-instructions.js | 27 +- .../mjsunit/wasm/shared-everything/basic.js | 36 +- .../gc-casts-shared-to-unshared.js | 6 +- .../gc-casts-subtypes-shared.js | 25 +- .../wasm/shared-everything/post-message.js | 30 +- .../shared-extended-instructions.js | 6 +- .../shared-type-with-unshared-elem.js | 6 +- .../wasm/shared-everything/spin-lock.js | 8 +- .../shared-everything/string-builtins-utf8.js | 389 ++ .../wasm/shared-everything/string-builtins.js | 824 +++++ .../mjsunit/wasm/shared-everything/strings.js | 92 + .../wasm/shared-everything/wait-queue.js | 289 ++ .../shared-everything/wrapper-type-checks.js | 9 +- ...ed-memory-resizable-buffer-array-concat.js | 1 - ...esizable-buffer-array-flat-flatmap-from.js | 1 - ...emory-resizable-buffer-array-flat-grows.js | 1 - ...ry-resizable-buffer-array-flatmap-grows.js | 1 - ...emory-resizable-buffer-array-from-grows.js | 1 - ...memory-resizable-buffer-array-pop-shift.js | 1 - ...izable-buffer-array-push-unshift-splice.js | 1 - ...red-memory-resizable-buffer-array-slice.js | 1 - .../shared-memory-resizable-buffer-errors.js | 2 - deps/v8/test/mjsunit/wasm/shuffles.js | 2 - .../test/mjsunit/wasm/simd-extract-replace.js | 18 + deps/v8/test/mjsunit/wasm/simd-reduce.js | 41 + .../mjsunit/wasm/simd-replace-lane-zero.js | 141 + .../v8/test/mjsunit/wasm/simd-rot64-no-xor.js | 96 + deps/v8/test/mjsunit/wasm/simd-xor-rot64.js | 98 + .../test/mjsunit/wasm/speculative-inlining.js | 7 +- .../mjsunit/wasm/stack-switching-argswitch.js | 188 + .../wasm/stack-switching-no-cont-leak.js | 83 + .../mjsunit/wasm/stack-switching-params.js | 55 + .../wasm/stack-switching-switch-loop.js | 83 + .../mjsunit/wasm/stack-switching-switch.js | 217 ++ deps/v8/test/mjsunit/wasm/stack-switching.js | 41 +- .../mjsunit/wasm/stringref-array-nonetype.js | 2 +- .../mjsunit/wasm/stringref-instance-type.js | 2 +- .../test/mjsunit/wasm/stringref-memory64.js | 2 +- .../test/mjsunit/wasm/stringrefs-exec-gc.js | 12 +- deps/v8/test/mjsunit/wasm/stringrefs-exec.js | 2 +- .../test/mjsunit/wasm/stringrefs-invalid.js | 2 +- deps/v8/test/mjsunit/wasm/stringrefs-js.js | 2 +- .../mjsunit/wasm/stringrefs-regressions.js | 9 +- deps/v8/test/mjsunit/wasm/stringrefs-valid.js | 16 +- .../mjsunit/wasm/stringview-valuestack.js | 2 +- .../v8/test/mjsunit/wasm/subtyping-invalid.js | 122 +- deps/v8/test/mjsunit/wasm/table-fill.js | 2 +- .../test/mjsunit/wasm/table-grow-from-wasm.js | 4 +- .../v8/test/mjsunit/wasm/table-numeric-ops.js | 38 +- .../test/mjsunit/wasm/table64-callindirect.js | 4 +- .../wasm/turboshaft/array-new-unreachable.js | 6 +- deps/v8/test/mjsunit/wasm/turboshaft/basic.js | 3 +- .../wasm/turboshaft/br-table-analysis.js | 3 +- .../wasm/turboshaft/instruction-selection.js | 6 +- .../mjsunit/wasm/turboshaft/int64-lowering.js | 3 +- .../turboshaft/load-elimination-revisits.js | 4 +- .../wasm/turboshaft/reduction-shuffle.js | 3 +- .../wasm/turboshaft/regress-crbug-1513580.js | 2 - .../turboshaft/regress-crbug-420998402.js | 2 - .../mjsunit/wasm/type-based-optimizations.js | 28 +- .../mjsunit/wasm/type-reflection-exnref.js | 21 - .../wasm/type-reflection-other-callable.js | 8 +- .../wasm/type-reflection-with-externref.js | 61 +- .../mjsunit/wasm/type-reflection-with-mv.js | 8 +- .../type-reflection-wrap-wasm-function.js | 6 +- deps/v8/test/mjsunit/wasm/type-reflection.js | 746 ---- .../test/mjsunit/wasm/wasm-code-coverage.js | 4 +- .../wasm/wasm-gc-externalize-internalize.js | 2 +- .../wasm/wasm-gc-inlining-load-elimination.js | 2 +- .../mjsunit/wasm/wasm-gc-inlining-nested.js | 2 +- .../wasm/wasm-gc-inlining-stacktrace-api.js | 193 +- deps/v8/test/mjsunit/wasm/wasm-gc-inlining.js | 16 +- .../test/mjsunit/wasm/wasm-gc-js-roundtrip.js | 2 +- .../wasm/wasm-inlining-catch-unreachable.js | 5 +- .../mjsunit/wasm/wasm-interpreter-memory64.js | 2 +- deps/v8/test/mjsunit/wasm/wasm-interpreter.js | 43 +- .../test/mjsunit/wasm/wasm-module-builder.js | 419 ++- .../v8/test/mjsunit/wasm/wasm-to-js-tierup.js | 37 +- .../wasm/wasm-wrapper-inlining-turbolev.js | 10 + .../mjsunit/wasm/wasmfx-load-elimination.js | 57 + deps/v8/test/mjsunit/wasm/wide-arithmetic.js | 302 ++ .../wrapper-inlining-lazy-deopt-turbolev.js | 10 + .../wasm/wrapper-inlining-lazy-deopt.js | 2 +- .../built-ins/RegExp/escape/surrogate-pair.js | 9 - .../local-tests/test/staging/features.txt | 33 +- deps/v8/test/test262/test262.status | 229 +- deps/v8/test/test262/testcfg.py | 4 +- deps/v8/test/torque/test-torque.tq | 219 +- deps/v8/test/unittests/BUILD.gn | 62 +- .../unittests/api/access-check-unittest.cc | 10 +- .../test/unittests/api/accessor-unittest.cc | 2 +- .../test/unittests/api/api-wasm-unittest.cc | 40 +- .../unittests/api/deserialize-unittest.cc | 42 +- .../api/dictionary-template-unittest.cc | 8 +- .../unittests/api/interceptor-unittest.cc | 16 +- .../api/resource-constraints-unittest.cc | 9 +- .../test/unittests/api/v8-object-unittest.cc | 2 +- .../assembler/assembler-arm64-unittest.cc | 34 + .../assembler/assembler-loong64-unittest.cc | 71 +- .../assembler/assembler-riscv64-unittest.cc | 913 +++++ .../assembler/assembler-x64-unittest.cc | 180 +- .../assembler/disasm-arm64-unittest.cc | 50 +- .../assembler/disasm-riscv-unittest.cc | 61 + .../assembler/disasm-x64-unittest.cc | 193 + .../macro-assembler-riscv64-unittest.cc | 572 ++- .../assembler/simple-riscv64-unittest.cc | 1 + deps/v8/test/unittests/base/asan-unittest.cc | 50 + deps/v8/test/unittests/base/cpu-unittest.cc | 5 +- .../test/unittests/base/hashmap-unittest.cc | 2 +- .../test/unittests/base/logging-unittest.cc | 6 +- .../base/platform/platform-unittest.cc | 6 +- .../codegen/code-stub-assembler-unittest.cc | 25 +- .../codegen/safepoint-table-unittest.cc | 403 ++ ...aft-instruction-selector-arm64-unittest.cc | 911 ++++- ...turboshaft-instruction-selector-unittest.h | 26 + .../unittests/compiler/compiler-unittest.cc | 2 +- ...t-instruction-selector-loong64-unittest.cc | 103 + .../machine-operator-reducer-unittest.cc | 1 + .../test/unittests/compiler/revec-unittest.cc | 80 +- ...t-instruction-selector-riscv64-unittest.cc | 197 +- .../run-bytecode-graph-builder-unittest.cc | 315 +- .../load-store-address-hoisting-unittest.cc | 18 +- .../machine-optimization-reducer-unittest.cc | 259 ++ .../compiler/turboshaft/reducer-test.h | 31 +- .../turboshaft/typeswitch-unittest.cc | 3 + .../wasm-shuffle-reducer-unittest.cc | 574 ++- .../compiler/turboshaft/wasm-simd-unittest.cc | 177 + .../wasm-address-reassociation-unittest.cc | 72 +- ...shaft-instruction-selector-x64-unittest.cc | 247 +- .../debug/debug-property-iterator-unittest.cc | 2 +- .../unittests/dumpling/dumpling-unittest.cc | 842 ++++- .../execution/thread-termination-unittest.cc | 20 +- .../unittests/heap/base/bytes-unittest.cc | 5 +- .../conservative-stack-visitor-unittest.cc | 10 +- .../cpp-heap-stack-start-marker-unittest.cc | 68 + .../unified-heap-snapshot-unittest.cc | 219 +- .../heap/cppgc/allocation-unittest.cc | 10 +- .../heap/cppgc/ephemeron-pair-unittest.cc | 3 +- .../heap/cppgc/name-trait-unittest.cc | 2 +- .../heap/cppgc/page-memory-unittest.cc | 20 +- .../heap/cppgc/stack-start-marker-unittest.cc | 48 + .../unittests/heap/cppgc/stack-unittest.cc | 4 +- .../test/unittests/heap/gc-tracer-unittest.cc | 27 + .../unittests/heap/heap-allocator-unittest.cc | 11 +- .../heap/heap-controller-unittest.cc | 49 +- deps/v8/test/unittests/heap/heap-unittest.cc | 217 +- .../heap/inner-pointer-resolution-unittest.cc | 3 +- .../unittests/heap/local-factory-unittest.cc | 3 +- .../unittests/heap/minimal-stack-unittest.cc | 100 + .../unittests/heap/shared-heap-unittest.cc | 50 +- .../v8/test/unittests/heap/spaces-unittest.cc | 15 +- .../bytecode-array-builder-unittest.cc | 88 +- .../interpreter/bytecode-decoder-unittest.cc | 6 +- .../bytecode-expectations-printer.cc | 8 +- .../bytecode_expectations/AsyncModules.golden | 68 +- .../BasicBlockToBoolean.golden | 12 +- .../bytecode_expectations/BasicLoops.golden | 74 +- .../BreakableBlocks.golden | 10 +- .../ClassDeclarations.golden | 2 +- .../bytecode_expectations/Conditional.golden | 2 +- .../ConstVariableContextSlot.golden | 2 +- .../DeclareGlobals.golden | 8 +- .../ElideRedundantHoleChecks.golden | 4 +- .../bytecode_expectations/ForAwaitOf.golden | 16 +- .../bytecode_expectations/ForIn.golden | 12 +- .../bytecode_expectations/ForOf.golden | 12 +- .../HoleCheckElision.golden | 253 ++ .../bytecode_expectations/IIFE.golden | 2 +- .../bytecode_expectations/IfConditions.golden | 12 +- .../LogicalExpressions.golden | 8 +- .../PrivateAccessorAccess.golden | 8 +- .../PrivateFieldSpecializedBytecode.golden | 78 + .../PrivateMethodAccess.golden | 10 +- .../PropertyLoadStore.golden | 2 +- .../RemoveRedundantLdar.golden | 6 +- .../StandardForLoop.golden | 50 +- .../StaticClassFields.golden | 4 +- .../StaticPrivateMethodAccess.golden | 48 +- .../bytecode_expectations/Switch.golden | 34 +- .../TopLevelObjectLiterals.golden | 14 +- .../bytecode_expectations/TryCatch.golden | 43 +- .../bytecode_expectations/TryFinally.golden | 55 +- .../UnaryOperators.golden | 8 +- .../VariableWithHint.golden | 10 +- .../WideRegisters.golden | 8 +- .../constant-array-builder-unittest.cc | 54 +- .../generate-bytecode-expectations.cc | 2 +- .../interpreter/interpreter-tester.cc | 38 +- .../interpreter/interpreter-tester.h | 12 +- .../interpreter/interpreter-unittest.cc | 31 +- .../unittests/libsampler/sampler-unittest.cc | 2 +- .../v8/test/unittests/logging/log-unittest.cc | 2 +- .../maglev/maglev-graph-builder-unittest.cc | 59 +- .../unittests/numbers/conversions-unittest.cc | 18 +- .../unittests/objects/array-list-unittest.cc | 8 +- .../objects/concurrent-js-array-unittest.cc | 4 +- ...oncurrent-script-context-table-unittest.cc | 8 +- .../objects/elements-kind-unittest.cc | 30 +- .../objects/global-object-unittest.cc | 8 +- .../unittests/objects/hashcode-unittest.cc | 18 +- .../test/unittests/objects/intl-unittest.cc | 4 +- .../unittests/objects/managed-unittest.cc | 58 +- .../objects/module-request-unittest.cc | 33 + .../test/unittests/objects/object-unittest.cc | 24 +- .../objects/value-serializer-unittest.cc | 13 +- .../objects/wasm-backing-store-unittest.cc | 10 +- .../objects/weakarraylist-unittest.cc | 22 +- .../test/unittests/parser/decls-unittest.cc | 7 +- .../test/unittests/parser/parsing-unittest.cc | 70 +- .../unittests/parser/preparser-unittest.cc | 4 +- .../parser/scanner-streams-unittest.cc | 31 + .../profiler/circular-queue-unittest.cc | 2 +- .../profiler/heap-snapshot-unittest.cc | 371 +- .../unittests/profiler/heap-snapshot-utils.cc | 83 + .../unittests/profiler/heap-snapshot-utils.h | 29 + .../profiler/strings-storage-unittest.cc | 18 + .../v8/test/unittests/regexp/regexp-fuzzer.cc | 12 +- .../test/unittests/regexp/regexp-unittest.cc | 830 +++-- deps/v8/test/unittests/run-all-unittests.cc | 3 +- .../runtime/runtime-debug-unittest.cc | 4 +- .../sandbox/bytecode-verifier-unittest.cc | 60 + .../sandbox/libcxx-hardening-unittest.cc | 48 + .../sandbox/pointer-table-unittest.cc | 9 +- .../unittests/sandbox/trap-fuzzer-unittest.cc | 83 + .../unittests/strings/unicode-unittest.cc | 65 - deps/v8/test/unittests/unittests.status | 7 + .../unittests/utils/bit-vector-unittest.cc | 40 + .../v8/test/unittests/utils/utils-unittest.cc | 11 +- .../wasm/compilation-hints-unittest.cc | 3 +- .../wasm/function-body-decoder-unittest.cc | 468 ++- .../unittests/wasm/leb-helper-unittest.cc | 3 - .../wasm/liftoff-register-unittests.cc | 5 +- .../unittests/wasm/module-decoder-unittest.cc | 34 +- .../wasm/signature-hashing-unittest.cc | 17 + ...imd-cross-compiler-determinism-fuzztest.cc | 541 ++- .../unittests/wasm/struct-types-unittest.cc | 21 +- .../test/unittests/wasm/subtyping-unittest.cc | 186 +- .../wasm/trap-handler-native-unittest.cc | 32 +- .../wasm/trap-handler-simulator-unittest.cc | 82 +- .../wasm/type-canonicalization-fuzztest.cc | 13 +- .../unittests/wasm/wasm-compiler-unittest.cc | 8 +- .../unittests/wasm/wasm-tracing-unittest.cc | 19 +- deps/v8/test/wasm-js/report.js | 46 +- deps/v8/test/wasm-js/testcfg.py | 10 +- deps/v8/test/wasm-js/tests.tar.gz.sha1 | 2 +- deps/v8/test/wasm-js/wasm-js.status | 9 +- deps/v8/test/wasm-spec-tests/testcfg.py | 92 +- .../v8/test/wasm-spec-tests/tests.tar.gz.sha1 | 2 +- .../wasm-spec-tests/wasm-spec-tests.status | 16 +- .../fast/js/nested-object-gc-expected.txt | 32 + .../test/webkit/fast/js/nested-object-gc.js | 38 + deps/v8/third_party/abseil-cpp/BUILD.gn | 16 + .../abseil-cpp/CMake/AbseilDll.cmake | 157 +- deps/v8/third_party/abseil-cpp/CMakeLists.txt | 2 +- deps/v8/third_party/abseil-cpp/FAQ.md | 209 +- deps/v8/third_party/abseil-cpp/MODULE.bazel | 4 +- .../v8/third_party/abseil-cpp/README.chromium | 2 +- .../third_party/abseil-cpp/absl/BUILD.bazel | 6 + .../abseil-cpp/absl/algorithm/container.h | 16 +- .../abseil-cpp/absl/base/BUILD.bazel | 61 +- .../third_party/abseil-cpp/absl/base/BUILD.gn | 29 +- .../abseil-cpp/absl/base/CMakeLists.txt | 34 +- .../abseil-cpp/absl/base/attributes.h | 102 +- .../abseil-cpp/absl/base/call_once.h | 1 + .../third_party/abseil-cpp/absl/base/casts.h | 8 +- .../abseil-cpp/absl/base/casts_test.cc | 9 +- .../third_party/abseil-cpp/absl/base/config.h | 46 +- .../base/exception_safety_testing_test.cc | 8 +- .../abseil-cpp/absl/base/fast_type_id.h | 32 +- .../abseil-cpp/absl/base/fast_type_id_test.cc | 3 + .../base/internal/exception_safety_testing.h | 21 +- .../absl/base/internal/hardening.cc | 46 + .../abseil-cpp/absl/base/internal/hardening.h | 149 + .../absl/base/internal/hardening_test.cc | 168 + .../absl/base/internal/iterator_traits.h | 4 +- .../absl/base/internal/low_level_scheduling.h | 92 +- .../abseil-cpp/absl/base/internal/sysinfo.cc | 3 +- .../absl/base/internal/thread_identity.h | 52 + .../absl/base/internal/unscaledcycleclock.h | 4 + .../third_party/abseil-cpp/absl/base/macros.h | 13 +- .../abseil-cpp/absl/base/nullability.h | 1 + .../abseil-cpp/absl/base/optimization.h | 4 +- .../abseil-cpp/absl/base/optimization_test.cc | 7 +- .../abseil-cpp/absl/base/options.h | 54 + .../base/{internal => }/throw_delegate.cc | 16 +- .../absl/base/{internal => }/throw_delegate.h | 18 +- .../absl/base/throw_delegate_test.cc | 47 +- .../absl/cleanup/internal/cleanup.h | 2 +- .../abseil-cpp/absl/container/BUILD.bazel | 21 +- .../abseil-cpp/absl/container/BUILD.gn | 12 +- .../abseil-cpp/absl/container/CMakeLists.txt | 6 +- .../abseil-cpp/absl/container/btree_test.cc | 6 +- .../abseil-cpp/absl/container/fixed_array.h | 14 +- .../abseil-cpp/absl/container/flat_hash_map.h | 17 +- .../absl/container/flat_hash_map_test.cc | 35 +- .../abseil-cpp/absl/container/flat_hash_set.h | 15 +- .../absl/container/flat_hash_set_test.cc | 32 + .../absl/container/inlined_vector.h | 11 +- .../absl/container/internal/btree.h | 22 +- .../absl/container/internal/btree_container.h | 28 +- .../absl/container/internal/common.h | 11 +- .../container/internal/common_policy_traits.h | 2 +- .../container/internal/compressed_tuple.h | 10 +- .../internal/compressed_tuple_test.cc | 20 +- .../container/internal/container_memory.h | 6 +- .../internal/hash_function_defaults.h | 4 +- .../internal/hash_generator_testing.h | 6 +- .../container/internal/hash_policy_traits.h | 6 +- .../internal/hashtable_control_bytes.h | 46 +- .../container/internal/hashtablez_sampler.cc | 1 - .../container/internal/hashtablez_sampler.h | 17 - .../internal/hashtablez_sampler_test.cc | 42 +- .../absl/container/internal/inlined_vector.h | 28 +- .../absl/container/internal/layout.h | 4 +- .../absl/container/internal/raw_hash_map.h | 122 +- .../absl/container/internal/raw_hash_set.cc | 29 +- .../absl/container/internal/raw_hash_set.h | 592 +-- .../internal/raw_hash_set_benchmark.cc | 27 +- .../internal/raw_hash_set_probe_benchmark.cc | 8 +- .../container/internal/raw_hash_set_test.cc | 390 +- .../absl/container/linked_hash_map.h | 31 +- .../absl/container/linked_hash_map_test.cc | 23 + .../absl/container/linked_hash_set.h | 25 +- .../absl/container/linked_hash_set_test.cc | 30 + .../abseil-cpp/absl/container/node_hash_map.h | 17 +- .../absl/container/node_hash_map_test.cc | 34 + .../abseil-cpp/absl/container/node_hash_set.h | 15 +- .../absl/container/node_hash_set_test.cc | 32 + .../container/sample_element_size_test.cc | 11 +- .../abseil-cpp/absl/crc/BUILD.bazel | 1 - .../third_party/abseil-cpp/absl/crc/BUILD.gn | 1 - .../abseil-cpp/absl/crc/CMakeLists.txt | 5 +- .../absl/crc/internal/cpu_detect.cc | 12 +- .../abseil-cpp/absl/crc/internal/crc.cc | 10 +- .../absl/crc/internal/crc_internal.h | 16 - .../abseil-cpp/absl/debugging/BUILD.bazel | 40 +- .../abseil-cpp/absl/debugging/BUILD.gn | 23 +- .../abseil-cpp/absl/debugging/CMakeLists.txt | 36 +- .../internal/borrowed_fixup_buffer.cc | 118 - .../internal/borrowed_fixup_buffer.h | 71 - .../internal/borrowed_fixup_buffer_test.cc | 97 - .../absl/debugging/internal/demangle_rust.h | 8 + .../absl/debugging/internal/examine_stack.cc | 14 +- .../absl/debugging/internal/examine_stack.h | 5 +- .../absl/debugging/internal/symbolize.h | 82 +- .../abseil-cpp/absl/debugging/stacktrace.cc | 76 +- .../abseil-cpp/absl/debugging/stacktrace.h | 53 +- .../absl/debugging/stacktrace_test.cc | 124 - .../abseil-cpp/absl/debugging/symbolize.cc | 22 +- .../absl/debugging/symbolize_elf.inc | 164 +- .../absl/debugging/symbolize_test.cc | 71 +- .../debugging/symbolize_unimplemented.inc | 8 +- .../abseil-cpp/absl/flags/BUILD.bazel | 9 +- .../abseil-cpp/absl/flags/BUILD.gn | 2 +- .../abseil-cpp/absl/flags/CMakeLists.txt | 2 +- .../abseil-cpp/absl/flags/commandlineflag.h | 14 +- .../abseil-cpp/absl/flags/flag_benchmark.cc | 10 +- .../abseil-cpp/absl/flags/flag_test.cc | 60 +- .../abseil-cpp/absl/flags/internal/flag.h | 8 +- .../abseil-cpp/absl/flags/marshalling.h | 30 +- .../abseil-cpp/absl/flags/marshalling_test.cc | 23 +- .../abseil-cpp/absl/functional/BUILD.bazel | 1 - .../abseil-cpp/absl/functional/BUILD.gn | 1 - .../abseil-cpp/absl/functional/CMakeLists.txt | 1 - .../absl/functional/any_invocable.h | 18 +- .../absl/functional/any_invocable_test.cc | 43 +- .../abseil-cpp/absl/functional/bind_front.h | 6 + .../absl/functional/internal/any_invocable.h | 46 +- .../absl/functional/internal/front_binder.h | 2 +- .../absl/functional/internal/function_ref.h | 4 +- .../absl/functional/overload_test.cc | 26 +- .../abseil-cpp/absl/hash/BUILD.bazel | 3 +- .../third_party/abseil-cpp/absl/hash/BUILD.gn | 3 +- .../abseil-cpp/absl/hash/CMakeLists.txt | 3 +- .../third_party/abseil-cpp/absl/hash/hash.h | 2 +- .../abseil-cpp/absl/hash/hash_test.cc | 32 +- .../abseil-cpp/absl/hash/hash_testing.h | 13 +- .../abseil-cpp/absl/hash/internal/city.cc | 90 +- .../abseil-cpp/absl/hash/internal/hash.cc | 212 +- .../abseil-cpp/absl/hash/internal/hash.h | 109 +- .../absl/hash/internal/low_level_hash_test.cc | 37 +- .../absl/hash/internal/spy_hash_state.h | 13 +- .../abseil-cpp/absl/log/BUILD.bazel | 6 +- .../third_party/abseil-cpp/absl/log/BUILD.gn | 6 +- .../abseil-cpp/absl/log/CMakeLists.txt | 7 +- .../abseil-cpp/absl/log/internal/BUILD.bazel | 10 +- .../abseil-cpp/absl/log/internal/BUILD.gn | 2 +- .../absl/log/internal/log_message.cc | 3 +- .../absl/log/internal/log_message.h | 7 + .../abseil-cpp/absl/log/internal/nullstream.h | 2 +- .../absl/log/internal/structured_proto.cc | 10 +- .../absl/log/internal/structured_proto.h | 11 +- .../absl/log/internal/vlog_config.cc | 4 +- .../abseil-cpp/absl/log/log_format_test.cc | 5 +- .../absl/log/log_modifier_methods_test.cc | 18 + .../abseil-cpp/absl/log/log_streamer.h | 29 +- .../abseil-cpp/absl/log/log_streamer_test.cc | 18 + .../abseil-cpp/absl/log/vlog_is_on_test.cc | 11 +- .../abseil-cpp/absl/memory/memory.h | 49 +- .../abseil-cpp/absl/memory/memory_test.cc | 38 + .../abseil-cpp/absl/meta/BUILD.bazel | 2 + .../abseil-cpp/absl/meta/internal/requires.h | 2 +- .../abseil-cpp/absl/meta/type_traits.h | 173 +- .../abseil-cpp/absl/meta/type_traits_test.cc | 14 +- .../abseil-cpp/absl/numeric/int128_test.cc | 12 +- .../abseil-cpp/absl/profiling/BUILD.bazel | 4 +- .../abseil-cpp/absl/profiling/hashtable.cc | 4 - .../profiling/internal/profile_builder.cc | 65 +- .../absl/profiling/internal/profile_builder.h | 27 +- .../internal/sample_recorder_test.cc | 13 +- .../abseil-cpp/absl/random/BUILD.bazel | 14 +- .../abseil-cpp/absl/random/BUILD.gn | 19 +- .../abseil-cpp/absl/random/CMakeLists.txt | 25 +- .../abseil-cpp/absl/random/benchmarks.cc | 2 +- .../absl/random/beta_distribution.h | 4 +- .../abseil-cpp/absl/random/bit_gen_ref.h | 84 +- .../absl/random/bit_gen_ref_test.cc | 43 + .../abseil-cpp/absl/random/distributions.h | 34 +- .../absl/random/distributions_test.cc | 8 +- .../absl/random/exponential_distribution.h | 2 +- .../absl/random/internal/BUILD.bazel | 6 +- .../abseil-cpp/absl/random/internal/BUILD.gn | 5 +- .../random/internal/distribution_caller.h | 27 +- .../absl/random/internal/fast_uniform_bits.h | 2 +- .../absl/random/internal/generate_real.h | 2 +- .../random/internal/iostream_state_saver.h | 4 +- .../internal/iostream_state_saver_test.cc | 5 +- .../absl/random/internal/mock_helpers.h | 54 +- .../absl/random/internal/nonsecure_base.h | 4 +- .../random/internal/nonsecure_base_test.cc | 4 +- .../absl/random/internal/pcg_engine.h | 12 +- .../absl/random/internal/pcg_engine_test.cc | 5 +- .../absl/random/internal/randen_detect.cc | 12 +- .../absl/random/internal/randen_engine.h | 4 +- .../random/internal/randen_engine_test.cc | 5 +- .../absl/random/internal/randen_test.cc | 5 +- .../absl/random/internal/salted_seed_seq.h | 7 +- .../absl/random/internal/seed_material.cc | 8 +- .../absl/random/internal/seed_material.h | 3 +- .../abseil-cpp/absl/random/internal/traits.h | 21 + .../absl/random/internal/traits_test.cc | 5 + .../absl/random/internal/uniform_helper.h | 46 +- .../random/internal/uniform_helper_test.cc | 3 +- .../abseil-cpp/absl/random/mocking_access.h | 74 + .../abseil-cpp/absl/random/mocking_bit_gen.h | 22 +- .../absl/random/uniform_real_distribution.h | 2 +- .../abseil-cpp/absl/status/BUILD.bazel | 8 + .../abseil-cpp/absl/status/BUILD.gn | 7 + .../abseil-cpp/absl/status/CMakeLists.txt | 5 + .../absl/status/internal/status_internal.cc | 45 +- .../absl/status/internal/status_internal.h | 13 +- .../absl/status/internal/status_matchers.h | 30 +- .../absl/status/internal/statusor_internal.h | 80 +- .../abseil-cpp/absl/status/status.cc | 132 +- .../abseil-cpp/absl/status/status.h | 271 +- .../absl/status/status_benchmark.cc | 12 + .../abseil-cpp/absl/status/status_matchers.h | 3 +- .../absl/status/status_matchers_test.cc | 7 +- .../absl/status/status_payload_printer.h | 5 +- .../abseil-cpp/absl/status/status_test.cc | 456 ++- .../abseil-cpp/absl/status/statusor.h | 73 +- .../abseil-cpp/absl/status/statusor_test.cc | 141 +- .../abseil-cpp/absl/strings/BUILD.bazel | 42 +- .../abseil-cpp/absl/strings/BUILD.gn | 51 +- .../abseil-cpp/absl/strings/CMakeLists.txt | 33 +- .../abseil-cpp/absl/strings/ascii.h | 3 +- .../absl/strings/atod_manual_test.cc | 10 +- .../abseil-cpp/absl/strings/cord.cc | 8 +- .../abseil-cpp/absl/strings/cord.h | 19 +- .../abseil-cpp/absl/strings/cord_test.cc | 46 +- .../abseil-cpp/absl/strings/escaping.cc | 218 +- .../abseil-cpp/absl/strings/escaping.h | 10 +- .../absl/strings/escaping_benchmark.cc | 4 +- .../abseil-cpp/absl/strings/escaping_test.cc | 40 +- .../absl/strings/has_absl_stringify_test.cc | 4 +- .../absl/strings/has_ostream_operator_test.cc | 4 +- .../strings/internal/append_and_overwrite.h | 11 +- .../internal/damerau_levenshtein_distance.cc | 6 + .../internal/damerau_levenshtein_distance.h | 1 + .../absl/strings/internal/escaping.cc | 141 - .../absl/strings/internal/escaping.h | 28 +- .../internal/generic_printer_internal.h | 21 +- .../strings/internal/resize_uninitialized.h | 55 +- .../internal/resize_uninitialized_test.cc | 57 +- .../absl/strings/internal/stl_type_traits.h | 78 +- .../absl/strings/internal/str_format/arg.h | 36 +- .../internal/str_format/convert_test.cc | 32 +- .../internal/str_format/float_conversion.cc | 821 +++-- .../absl/strings/internal/str_join_internal.h | 1 - .../strings/internal/str_split_internal.h | 19 +- .../strings/internal/string_constant_test.cc | 11 +- .../absl/strings/internal/stringify_sink.h | 12 + .../absl/strings/internal/stringify_stream.h | 119 + .../strings/internal/stringify_stream_test.cc | 111 + .../absl/strings/resize_and_overwrite.h | 4 +- .../abseil-cpp/absl/strings/str_cat.h | 1 - .../absl/strings/str_cat_benchmark.cc | 3 +- .../abseil-cpp/absl/strings/str_split_test.cc | 13 + .../absl/synchronization/BUILD.bazel | 3 + .../internal/create_thread_identity.cc | 21 + .../synchronization/internal/per_thread_sem.h | 5 + .../abseil-cpp/absl/synchronization/mutex.cc | 13 + .../abseil-cpp/absl/synchronization/mutex.h | 34 +- .../absl/synchronization/mutex_test.cc | 14 + .../abseil-cpp/absl/time/BUILD.bazel | 80 + .../third_party/abseil-cpp/absl/time/BUILD.gn | 52 + .../abseil-cpp/absl/time/CMakeLists.txt | 73 + .../third_party/abseil-cpp/absl/time/clock.h | 3 + .../abseil-cpp/absl/time/clock_interface.cc | 71 + .../abseil-cpp/absl/time/clock_interface.h | 93 + .../absl/time/clock_interface_test.cc | 128 + .../abseil-cpp/absl/time/format_test.cc | 5 + .../internal/cctz/src/time_zone_format.cc | 179 +- .../cctz/src/time_zone_format_test.cc | 85 +- .../internal/cctz/src/time_zone_name_win.cc | 3 +- .../absl/time/internal/cctz/src/tzfile.h | 25 +- .../absl/time/internal/cctz/testdata/version | 2 +- .../cctz/testdata/zoneinfo/Asia/Tbilisi | Bin 629 -> 620 bytes .../cctz/testdata/zoneinfo/Europe/Chisinau | Bin 755 -> 1207 bytes .../cctz/testdata/zoneinfo/Europe/Tiraspol | Bin 755 -> 1207 bytes .../cctz/testdata/zoneinfo/zonenow.tab | 3 - .../abseil-cpp/absl/time/simulated_clock.cc | 225 ++ .../abseil-cpp/absl/time/simulated_clock.h | 109 + .../absl/time/simulated_clock_test.cc | 614 ++++ .../abseil-cpp/absl/types/BUILD.bazel | 114 + .../abseil-cpp/absl/types/BUILD.gn | 55 + .../abseil-cpp/absl/types/CMakeLists.txt | 98 + .../abseil-cpp/absl/types/any_span.h | 1067 ++++++ .../absl/types/any_span_benchmark.cc | 258 ++ .../abseil-cpp/absl/types/any_span_test.cc | 1210 ++++++ .../abseil-cpp/absl/types/compare.h | 8 +- .../abseil-cpp/absl/types/internal/any_span.h | 477 +++ .../abseil-cpp/absl/types/internal/span.h | 11 +- .../abseil-cpp/absl/types/optional_ref.h | 295 ++ .../absl/types/optional_ref_test.cc | 370 ++ .../abseil-cpp/absl/types/source_location.cc | 18 + .../abseil-cpp/absl/types/source_location.h | 172 + .../absl/types/source_location_test.cc | 139 + .../third_party/abseil-cpp/absl/types/span.h | 42 +- .../0007-deprecated-base64-escape.patch | 26 + .../0008-deprecated-meta-type-traits.patch | 149 + ...-random-internal-transitive-includes.patch | 17 + .../abseil-cpp/symbols_arm64_dbg.def | 581 +-- .../abseil-cpp/symbols_arm64_dbg_cxx23.def | 565 +-- .../abseil-cpp/symbols_arm64_rel.def | 122 +- .../abseil-cpp/symbols_arm64_rel_cxx23.def | 122 +- .../abseil-cpp/symbols_x64_dbg.def | 636 ++-- .../abseil-cpp/symbols_x64_dbg_cxx23.def | 620 ++-- .../abseil-cpp/symbols_x64_rel.def | 125 +- .../abseil-cpp/symbols_x64_rel_asan.def | 126 +- .../abseil-cpp/symbols_x64_rel_asan_cxx23.def | 126 +- .../abseil-cpp/symbols_x64_rel_cxx23.def | 125 +- .../abseil-cpp/symbols_x86_dbg.def | 633 ++-- .../abseil-cpp/symbols_x86_dbg_cxx23.def | 617 ++-- .../abseil-cpp/symbols_x86_rel.def | 126 +- .../abseil-cpp/symbols_x86_rel_cxx23.def | 126 +- deps/v8/third_party/colorama/README.v8 | 2 +- deps/v8/third_party/dragonbox/README.v8 | 2 +- deps/v8/third_party/fast_float/README.v8 | 2 +- .../src/include/fast_float/ascii_number.h | 269 +- .../src/include/fast_float/bigint.h | 26 +- .../fast_float/constexpr_feature_detect.h | 9 +- .../include/fast_float/decimal_to_binary.h | 9 +- .../src/include/fast_float/digit_comparison.h | 27 +- .../src/include/fast_float/fast_float.h | 37 +- .../src/include/fast_float/float_common.h | 685 +++- .../src/include/fast_float/parse_number.h | 219 +- deps/v8/third_party/fp16/README.v8 | 2 +- deps/v8/third_party/glibc/README.v8 | 2 +- .../v8/third_party/googletest/README.chromium | 2 +- deps/v8/third_party/highway/README.chromium | 2 +- .../highway/src/hwy/aligned_allocator.h | 46 +- .../third_party/highway/src/hwy/auto_tune.h | 8 +- deps/v8/third_party/highway/src/hwy/base.h | 142 +- deps/v8/third_party/highway/src/hwy/bit_set.h | 268 +- .../highway/src/hwy/bit_set_test.cc | 127 +- .../highway/src/hwy/cache_control.h | 5 +- .../highway/src/hwy/contrib/algo/copy_test.cc | 25 - .../highway/src/hwy/contrib/algo/count-inl.h | 393 ++ .../src/hwy/contrib/algo/count_value_test.cc | 165 + .../highway/src/hwy/contrib/algo/find_test.cc | 34 +- .../highway/src/hwy/contrib/algo/minmax-inl.h | 102 + .../src/hwy/contrib/algo/minmax_value_test.cc | 165 + .../src/hwy/contrib/algo/transform_test.cc | 61 - .../src/hwy/contrib/bit_pack/bit_pack-inl.h | 4 +- .../highway/src/hwy/contrib/dot/dot_test.cc | 13 +- .../highway/src/hwy/contrib/image/image.cc | 15 +- .../src/hwy/contrib/math/fast_math-inl.h | 1736 +++++++++ .../highway/src/hwy/contrib/math/math-inl.h | 187 +- .../src/hwy/contrib/math/math_benchmark.cc | 326 ++ .../src/hwy/contrib/math/math_hyper_test.cc | 135 + .../src/hwy/contrib/math/math_tan_test.cc | 213 +- .../highway/src/hwy/contrib/math/math_test.cc | 479 ++- .../src/hwy/contrib/matvec/matvec_test.cc | 3 +- .../src/hwy/contrib/random/random-inl.h | 5 +- .../highway/src/hwy/contrib/sort/algo-inl.h | 34 +- .../src/hwy/contrib/sort/bench_sort.cc | 2 +- .../src/hwy/contrib/sort/print_network.cc | 2 +- .../highway/src/hwy/contrib/sort/shared-inl.h | 8 +- .../src/hwy/contrib/sort/sort_unit_test.cc | 12 +- .../hwy/contrib/sort/sorting_networks-inl.h | 11 + .../src/hwy/contrib/thread_pool/futex.h | 35 +- .../src/hwy/contrib/thread_pool/spin.h | 16 +- .../hwy/contrib/thread_pool/thread_pool.cc | 31 + .../src/hwy/contrib/thread_pool/thread_pool.h | 926 ++++- .../contrib/thread_pool/thread_pool_test.cc | 28 +- .../src/hwy/contrib/thread_pool/topology.cc | 188 +- .../highway/src/hwy/detect_compiler_arch.h | 127 +- .../highway/src/hwy/detect_targets.h | 66 +- .../highway/src/hwy/examples/README.md | 55 + .../highway/src/hwy/examples/benchmark.cc | 2 +- .../src/hwy/examples/sum_array_advanced.cc | 175 + .../src/hwy/examples/sum_array_simple.cc | 78 + .../highway/src/hwy/highway_test.cc | 26 +- .../highway/src/hwy/nanobenchmark.h | 15 +- .../highway/src/hwy/nanobenchmark_test.cc | 14 +- .../highway/src/hwy/ops/arm_neon-inl.h | 121 +- .../highway/src/hwy/ops/arm_sve-inl.h | 329 +- .../highway/src/hwy/ops/emu128-inl.h | 19 +- .../highway/src/hwy/ops/generic_ops-inl.h | 378 +- .../highway/src/hwy/ops/loongarch_lasx-inl.h | 19 +- .../highway/src/hwy/ops/loongarch_lsx-inl.h | 22 +- .../highway/src/hwy/ops/ppc_vsx-inl.h | 118 +- .../third_party/highway/src/hwy/ops/rvv-inl.h | 315 +- .../highway/src/hwy/ops/scalar-inl.h | 18 +- .../highway/src/hwy/ops/set_macros-inl.h | 203 +- .../highway/src/hwy/ops/wasm_128-inl.h | 35 +- .../highway/src/hwy/ops/wasm_256-inl.h | 24 +- .../highway/src/hwy/ops/x86_128-inl.h | 321 +- .../highway/src/hwy/ops/x86_256-inl.h | 204 +- .../highway/src/hwy/ops/x86_512-inl.h | 264 +- .../highway/src/hwy/perf_counters.cc | 2 +- deps/v8/third_party/highway/src/hwy/print.cc | 2 +- .../third_party/highway/src/hwy/profiler.cc | 60 +- .../v8/third_party/highway/src/hwy/profiler.h | 558 +-- .../highway/src/hwy/robust_statistics.h | 4 +- deps/v8/third_party/highway/src/hwy/stats.cc | 17 +- deps/v8/third_party/highway/src/hwy/stats.h | 69 +- .../v8/third_party/highway/src/hwy/targets.cc | 26 +- .../highway/src/hwy/tests/arithmetic_test.cc | 181 - .../highway/src/hwy/tests/compare_128_test.cc | 299 ++ .../highway/src/hwy/tests/compare_test.cc | 415 --- .../highway/src/hwy/tests/compress_test.cc | 18 +- .../highway/src/hwy/tests/crypto_test.cc | 4 +- .../highway/src/hwy/tests/demote_test.cc | 22 +- .../highway/src/hwy/tests/float_test.cc | 32 +- .../highway/src/hwy/tests/fma_test.cc | 5 +- .../highway/src/hwy/tests/hwy_gtest.h | 91 +- .../tests/in_range_float_to_int_conv_test.cc | 11 +- .../highway/src/hwy/tests/list_targets.cc | 15 +- .../highway/src/hwy/tests/logical_test.cc | 23 +- .../highway/src/hwy/tests/mask_mem_test.cc | 2 +- .../highway/src/hwy/tests/mask_set_test.cc | 10 +- .../highway/src/hwy/tests/mask_test.cc | 17 +- .../src/hwy/tests/masked_compare_test.cc | 203 + .../src/hwy/tests/minmax_number_test.cc | 5 +- .../highway/src/hwy/tests/minmax_test.cc | 5 +- .../highway/src/hwy/tests/neg_test.cc | 227 ++ .../highway/src/hwy/tests/shuffle4_test.cc | 3 +- .../src/hwy/tests/slide_up_down_test.cc | 2 - .../src/hwy/tests/swizzle_block_test.cc | 60 +- .../highway/src/hwy/tests/table_test.cc | 112 +- .../highway/src/hwy/tests/test_util-inl.h | 29 +- .../highway/src/hwy/tests/test_util.h | 102 +- deps/v8/third_party/highway/src/hwy/timer.h | 44 + .../third_party/inspector_protocol/README.v8 | 1 + .../crdtp/json_platform_v8.cc | 5 +- deps/v8/third_party/jsoncpp/README.chromium | 3 +- deps/v8/third_party/llvm-libc/README.v8 | 2 +- .../third_party/rapidhash-v8/README.chromium | 2 +- deps/v8/third_party/simdutf/BUILD.gn | 6 + deps/v8/third_party/v8/builtins/array-sort.h | 13 + deps/v8/third_party/v8/builtins/array-sort.tq | 635 ++-- deps/v8/third_party/wasm-api/README.v8 | 17 +- deps/v8/third_party/zlib/CMakeLists.txt | 394 +- deps/v8/third_party/zlib/LICENSE | 33 +- deps/v8/third_party/zlib/README | 115 + deps/v8/third_party/zlib/README.chromium | 8 +- deps/v8/third_party/zlib/chromeconf.h | 13 +- deps/v8/third_party/zlib/compress.c | 51 +- .../third_party/zlib/contrib/minizip/Makefile | 10 +- .../zlib/contrib/minizip/README.chromium | 7 +- .../third_party/zlib/contrib/minizip/crypt.h | 11 +- .../third_party/zlib/contrib/minizip/ioapi.c | 10 +- .../third_party/zlib/contrib/minizip/ioapi.h | 16 +- .../zlib/contrib/minizip/iowin32.c | 7 +- .../zlib/contrib/minizip/iowin32.h | 7 +- .../zlib/contrib/minizip/miniunz.c | 32 +- .../zlib/contrib/minizip/minizip.c | 13 +- .../zlib/contrib/minizip/mztools.c | 10 +- .../zlib/contrib/minizip/skipset.h | 157 +- .../third_party/zlib/contrib/minizip/unzip.c | 53 +- .../third_party/zlib/contrib/minizip/unzip.h | 9 +- .../v8/third_party/zlib/contrib/minizip/zip.c | 283 +- .../v8/third_party/zlib/contrib/minizip/zip.h | 11 +- .../contrib/optimizations/inffast_chunk.c | 10 +- .../zlib/contrib/optimizations/inflate.c | 2 +- deps/v8/third_party/zlib/crc32.c | 166 +- deps/v8/third_party/zlib/deflate.c | 186 +- deps/v8/third_party/zlib/deflate.h | 8 +- deps/v8/third_party/zlib/doc/algorithm.txt | 209 ++ deps/v8/third_party/zlib/doc/crc-doc.1.0.pdf | Bin 0 -> 776142 bytes deps/v8/third_party/zlib/doc/rfc1950.txt | 619 ++++ deps/v8/third_party/zlib/doc/rfc1951.txt | 955 +++++ deps/v8/third_party/zlib/doc/rfc1952.txt | 675 ++++ deps/v8/third_party/zlib/doc/txtvsbin.txt | 107 + deps/v8/third_party/zlib/examples/zpipe.c | 5 +- deps/v8/third_party/zlib/gzguts.h | 69 +- deps/v8/third_party/zlib/gzlib.c | 103 +- deps/v8/third_party/zlib/gzread.c | 298 +- deps/v8/third_party/zlib/gzwrite.c | 267 +- deps/v8/third_party/zlib/infback.c | 89 +- deps/v8/third_party/zlib/inffast.c | 13 +- deps/v8/third_party/zlib/inffixed.h | 182 +- deps/v8/third_party/zlib/inflate.c | 189 +- deps/v8/third_party/zlib/inflate.h | 2 +- deps/v8/third_party/zlib/inftrees.c | 143 +- deps/v8/third_party/zlib/inftrees.h | 4 +- .../third_party/zlib/patches/0000-build.patch | 8 +- .../zlib/patches/0004-fix-uwp.patch | 8 +- .../0008-minizip-zip-unzip-tools.patch | 22 +- .../zlib/patches/0010-cmake-enable-simd.patch | 96 - .../third_party/zlib/patches/0010-cmake.patch | 256 ++ .../zlib/patches/0011-avx512.patch | 28 - .../patches/0018-support-prefixed-zip64.patch | 6 +- .../zlib/patches/0019-fix-zip64-in-zip.patch | 37 + deps/v8/third_party/zlib/test/minigzip.c | 89 +- deps/v8/third_party/zlib/trees.c | 28 +- deps/v8/third_party/zlib/uncompr.c | 62 +- deps/v8/third_party/zlib/win32/zlib1.rc | 37 + deps/v8/third_party/zlib/zconf.h | 44 +- deps/v8/third_party/zlib/zconf.h.cmakein | 545 --- deps/v8/third_party/zlib/zconf.h.in | 46 +- deps/v8/third_party/zlib/zlib.3 | 22 +- deps/v8/third_party/zlib/zlib.h | 311 +- deps/v8/third_party/zlib/zlib.pc.cmakein | 9 +- deps/v8/third_party/zlib/zlibConfig.cmake.in | 18 + deps/v8/third_party/zlib/zutil.c | 85 +- deps/v8/third_party/zlib/zutil.h | 99 +- deps/v8/tools/bazel/bazel.sha1 | 2 +- .../tools/builtins-pgo/download_profiles.py | 19 +- .../builtins-pgo/download_profiles_test.py | 121 +- deps/v8/tools/builtins-pgo/get_hints.py | 25 +- deps/v8/tools/cluster_files.py | 252 ++ .../tools/clusterfuzz/foozzie/v8_foozzie.py | 15 +- .../clusterfuzz/foozzie/v8_foozzie_test.py | 20 + .../clusterfuzz/foozzie/v8_fuzz_flags.json | 15 +- .../clusterfuzz/foozzie/v8_mock_archs.js | 14 +- deps/v8/tools/clusterfuzz/js_fuzzer/README.md | 61 +- deps/v8/tools/clusterfuzz/js_fuzzer/corpus.js | 3 +- .../js_fuzzer/differential_script_mutator.js | 9 +- .../tools/clusterfuzz/js_fuzzer/exceptions.js | 283 +- .../js_fuzzer/mutators/crossover_mutator.js | 31 +- .../mutators/memory_corruption_mutator.js | 48 + .../tools/clusterfuzz/js_fuzzer/package.json | 2 +- .../resources/sandbox_fuzz_library.js | 311 ++ deps/v8/tools/clusterfuzz/js_fuzzer/run.js | 8 +- .../clusterfuzz/js_fuzzer/script_mutator.js | 22 + .../clusterfuzz/js_fuzzer/source_helpers.js | 11 +- .../clusterfuzz/js_fuzzer/test/helpers.js | 2 +- .../js_fuzzer/test/test_memory_corruptions.js | 39 + .../js_fuzzer/test/test_regressions.js | 14 + .../test_data/memory_corruption/input.js | 28 + .../memory_corruption/output_expected.js | 40 + .../regress/await/db/AwaitExpression/a1.json | 7 + .../test_data/regress/await/db/index.json | 3 + .../test_data/regress/await/expected.js | 31 + .../test_data/regress/await/input.js | 29 + .../v8/test/mjsunit/test1_expected.js | 4 + .../js_fuzzer/tools/run_locally_against_d8.py | 321 ++ .../trials/clusterfuzz_trials_config.json | 17 +- deps/v8/tools/cpu.sh | 13 +- deps/v8/tools/dev/gm.py | 140 +- deps/v8/tools/dev/setup_worktree_build.py | 49 + deps/v8/tools/dev/update-vscode.sh | 22 +- deps/v8/tools/find-d8.sh | 51 + deps/v8/tools/gcmole/gcmole-tools.tar.gz.sha1 | 2 +- deps/v8/tools/gdbinit | 58 +- deps/v8/tools/gen-postmortem-metadata.py | 3 +- deps/v8/tools/ic-processor | 33 +- deps/v8/tools/linux-tick-processor | 33 +- deps/v8/tools/logreader.mjs | 7 +- deps/v8/tools/mac-nm | 4 +- deps/v8/tools/package-lock.json | 486 ++- deps/v8/tools/parse-processor | 33 +- deps/v8/tools/profile.mjs | 133 +- deps/v8/tools/profiling/linux-perf-chrome.py | 6 +- deps/v8/tools/profiling/linux-perf-d8.py | 12 +- deps/v8/tools/run_perf.py | 282 +- .../v8/tools/sanitizers/tsan_suppressions.txt | 10 +- deps/v8/tools/system-analyzer/cli.mjs | 1302 +++++++ deps/v8/tools/system-analyzer/log/code.mjs | 60 + deps/v8/tools/system-analyzer/log/ic.mjs | 30 +- deps/v8/tools/system-analyzer/log/log.mjs | 12 + deps/v8/tools/system-analyzer/log/map.mjs | 25 +- deps/v8/tools/system-analyzer/processor.mjs | 41 +- deps/v8/tools/testrunner/base_runner.py | 48 +- deps/v8/tools/testrunner/build_config.py | 1 + deps/v8/tools/testrunner/local/android.py | 10 +- .../tools/testrunner/local/process_utils.py | 3 +- deps/v8/tools/testrunner/local/testsuite.py | 2 +- deps/v8/tools/testrunner/local/variants.py | 205 +- deps/v8/tools/testrunner/objects/output.py | 15 +- deps/v8/tools/testrunner/objects/testcase.py | 30 +- deps/v8/tools/testrunner/outproc/base.py | 2 +- deps/v8/tools/testrunner/outproc/message.py | 6 +- .../tools/testrunner/standard_runner_test.py | 8 +- .../testrunner/testdata/v8_build_config.json | 3 +- deps/v8/tools/testrunner/testproc/fuzzer.py | 15 +- .../tools/testrunner/testproc/indicators.py | 3 +- .../testrunner/testproc/indicators_test.py | 87 + deps/v8/tools/turbolizer/package-lock.json | 368 +- deps/v8/tools/turboshaft-stacktrace-filter.py | 69 + deps/v8/tools/turboshaft_type_formatter.py | 84 + deps/v8/tools/unittests/run_perf_test.py | 366 +- deps/v8/tools/v8-logviewer | 41 + .../wasm/mjsunit-module-disassembler-impl.h | 151 +- deps/v8/tools/wasm/module-inspector.cc | 42 +- deps/v8/tools/whitespace.txt | 4 +- 3548 files changed, 185349 insertions(+), 82382 deletions(-) create mode 100644 deps/v8/SECURITY.md create mode 100644 deps/v8/agents/.style.mdformat create mode 100644 deps/v8/agents/.vpython3 create mode 100644 deps/v8/agents/OWNERS create mode 100644 deps/v8/agents/README.md create mode 100644 deps/v8/agents/agents/builder/agent.json create mode 100644 deps/v8/agents/agents/builder/config.yaml create mode 100644 deps/v8/agents/agents/debugger/agent.json create mode 100644 deps/v8/agents/agents/debugger/config.yaml create mode 100644 deps/v8/agents/agents/researcher/agent.json create mode 100644 deps/v8/agents/agents/researcher/config.yaml create mode 100644 deps/v8/agents/agents/tester/agent.json create mode 100644 deps/v8/agents/agents/tester/config.yaml create mode 100644 deps/v8/agents/prompts/README.md rename deps/v8/{GEMINI.md => agents/prompts/common.md} (74%) create mode 100644 deps/v8/agents/prompts/templates/README.md create mode 100644 deps/v8/agents/prompts/templates/modular.md create mode 100644 deps/v8/agents/rules/debugging.md create mode 100644 deps/v8/agents/rules/execution-constraints.md create mode 100644 deps/v8/agents/rules/framework.md create mode 100644 deps/v8/agents/rules/git-cl.md create mode 100644 deps/v8/agents/rules/git-commit.md create mode 100644 deps/v8/agents/rules/torque.md create mode 100644 deps/v8/agents/rules/v8-best-practices.md create mode 100644 deps/v8/agents/rules/writing-skills.md create mode 100755 deps/v8/agents/scripts/analyze_brain.py create mode 100644 deps/v8/agents/scripts/cleanup_git_task.sh create mode 100755 deps/v8/agents/scripts/get_recent_commits.py create mode 100755 deps/v8/agents/scripts/install_for_gemini_cli.py create mode 100755 deps/v8/agents/scripts/install_for_jetski.py create mode 100644 deps/v8/agents/scripts/new_git_task.sh create mode 100644 deps/v8/agents/skills/README.md create mode 100644 deps/v8/agents/skills/agent-evaluation-framework/SKILL.md create mode 100644 deps/v8/agents/skills/agent-self-improvement/SKILL.md create mode 100644 deps/v8/agents/skills/clangd-setup/SKILL.md create mode 100644 deps/v8/agents/skills/crossbench/SKILL.md create mode 100644 deps/v8/agents/skills/doc-invalidation-checker/SKILL.md create mode 100644 deps/v8/agents/skills/ecmascript/SKILL.md create mode 100644 deps/v8/agents/skills/env-abstraction/SKILL.md create mode 100644 deps/v8/agents/skills/header-cycle-breaker/SKILL.md create mode 100644 deps/v8/agents/skills/jsvu/SKILL.md create mode 100644 deps/v8/agents/skills/orchestrator/SKILL.md create mode 100644 deps/v8/agents/skills/subagent-env-passing/SKILL.md create mode 100644 deps/v8/agents/skills/torque/SKILL.md create mode 100644 deps/v8/agents/skills/v8-ciderg-paths/SKILL.md create mode 100644 deps/v8/agents/skills/v8-commands/SKILL.md create mode 100644 deps/v8/agents/skills/v8-log/SKILL.md create mode 100644 deps/v8/agents/skills/v8-poc-classification/SKILL.md create mode 100644 deps/v8/agents/skills/v8-profile/SKILL.md create mode 100644 deps/v8/agents/skills/v8-setup/SKILL.md create mode 100644 deps/v8/agents/skills/v8-structure/SKILL.md create mode 100644 deps/v8/agents/skills/v8-testing/SKILL.md create mode 100644 deps/v8/agents/skills/v8-understanding/SKILL.md create mode 100644 deps/v8/agents/skills/v8-workflow/SKILL.md create mode 100644 deps/v8/agents/skills/workflow-debugging/SKILL.md create mode 100644 deps/v8/agents/skills/workflow-general-debugging/SKILL.md create mode 100644 deps/v8/agents/skills/workflow-perf/SKILL.md create mode 100755 deps/v8/agents/skills/workflow-perf/scripts/upload_and_pinpoint.py create mode 100644 deps/v8/agents/skills/workflow_gerrit_fix/SKILL.md create mode 100644 deps/v8/bazel/patches/BUILD.bazel create mode 100644 deps/v8/bazel/patches/highway_rules_cc.patch create mode 100644 deps/v8/docs/api.md create mode 100644 deps/v8/docs/become-committer.md create mode 100644 deps/v8/docs/benchmarks.md create mode 100644 deps/v8/docs/blink-layout-tests.md create mode 100644 deps/v8/docs/build-gn.md create mode 100644 deps/v8/docs/build.md create mode 100644 deps/v8/docs/builtin-functions.md create mode 100644 deps/v8/docs/builtins/architecture.md create mode 100644 deps/v8/docs/builtins/torque-tutorial.md create mode 100644 deps/v8/docs/codegen/assembler-architecture.md create mode 100644 deps/v8/docs/codegen/code-stub-assembler.md create mode 100644 deps/v8/docs/codegen/csa-tutorial.md create mode 100644 deps/v8/docs/committer-responsibility.md create mode 100644 deps/v8/docs/compile-arm64.md create mode 100644 deps/v8/docs/compiler/concurrency-and-background-compilation.md create mode 100644 deps/v8/docs/compiler/maglev/compiler-maglev-regalloc.md create mode 100644 deps/v8/docs/compiler/maglev/compiler-maglev.md create mode 100644 deps/v8/docs/compiler/sparkplug/compiler-sparkplug.md create mode 100644 deps/v8/docs/compiler/turbofan/compiler-turbofan.md create mode 100644 deps/v8/docs/compiler/turboshaft/compiler-turboshaft-copying-approach.md create mode 100644 deps/v8/docs/compiler/turboshaft/compiler-turboshaft-ir.md create mode 100644 deps/v8/docs/compiler/turboshaft/compiler-turboshaft-reducers.md create mode 100644 deps/v8/docs/compiler/turboshaft/compiler-turboshaft.md create mode 100644 deps/v8/docs/compiler/why-cfg.md create mode 100644 deps/v8/docs/contribute.md create mode 100644 deps/v8/docs/cross-compile-arm.md create mode 100644 deps/v8/docs/cross-compile-ios.md create mode 100644 deps/v8/docs/d8.md create mode 100644 deps/v8/docs/debug-arm.md create mode 100644 deps/v8/docs/design-review-guidelines.md create mode 100644 deps/v8/docs/embed.md create mode 100644 deps/v8/docs/evaluate-code-coverage.md create mode 100644 deps/v8/docs/feature-launch-process.md create mode 100644 deps/v8/docs/flake-bisect.md create mode 100644 deps/v8/docs/gdb-jit.md create mode 100644 deps/v8/docs/gdb.md create mode 100644 deps/v8/docs/heap/compaction.md create mode 100644 deps/v8/docs/heap/garbage-collection.md create mode 100644 deps/v8/docs/heap/handles.md create mode 100644 deps/v8/docs/heap/heap-overview.md create mode 100644 deps/v8/docs/heap/marking-and-sweeping.md create mode 100644 deps/v8/docs/heap/objects-and-maps.md create mode 100644 deps/v8/docs/heap/pointer-compression.md create mode 100644 deps/v8/docs/heap/pointer-tagging.md create mode 100644 deps/v8/docs/heap/roots.md create mode 100644 deps/v8/docs/heap/zone-allocator.md create mode 100644 deps/v8/docs/i18n.md create mode 100644 deps/v8/docs/ide-setup.md create mode 100644 deps/v8/docs/index.md create mode 100644 deps/v8/docs/inspector.md create mode 100644 deps/v8/docs/interpreter/interpreter-ignition.md create mode 100644 deps/v8/docs/javascript-overview.md create mode 100644 deps/v8/docs/linux-perf.md create mode 100644 deps/v8/docs/memory-leaks.md create mode 100644 deps/v8/docs/merge-patch.md create mode 100644 deps/v8/docs/node-integration.md create mode 100644 deps/v8/docs/objects/descriptor-and-transition-arrays.md create mode 100644 deps/v8/docs/objects/fields-and-elements.md create mode 100644 deps/v8/docs/objects/lookup-iterator.md create mode 100644 deps/v8/docs/objects/strings.md create mode 100644 deps/v8/docs/official-support.md create mode 100644 deps/v8/docs/overview.md create mode 100644 deps/v8/docs/parsing/lazy-parsing-and-preparser.md create mode 100644 deps/v8/docs/parsing/parser-and-ast.md create mode 100644 deps/v8/docs/ports.md create mode 100644 deps/v8/docs/profile-chromium.md create mode 100644 deps/v8/docs/profile.md create mode 100644 deps/v8/docs/rcs.md create mode 100644 deps/v8/docs/regexp/architecture.md create mode 100644 deps/v8/docs/release-process.md create mode 100644 deps/v8/docs/respectful-code.md create mode 100644 deps/v8/docs/runtime/deoptimization.md create mode 100644 deps/v8/docs/runtime/exception-handling.md create mode 100644 deps/v8/docs/runtime/function-architecture.md create mode 100644 deps/v8/docs/runtime/hidden-classes-and-ics.md create mode 100644 deps/v8/docs/runtime/hidden-classes-tutorial.md create mode 100644 deps/v8/docs/runtime/scopes-and-scope-infos.md create mode 100644 deps/v8/docs/runtime/stack-walking.md create mode 100644 deps/v8/docs/runtime/tiering.md create mode 100644 deps/v8/docs/sandbox/architecture.md create mode 100644 deps/v8/docs/security/reproducing-bugs.md create mode 100644 deps/v8/docs/security/triaging.md create mode 100644 deps/v8/docs/snapshot/architecture.md create mode 100644 deps/v8/docs/source-code.md create mode 100644 deps/v8/docs/stack-trace-api.md create mode 100644 deps/v8/docs/test.md create mode 100644 deps/v8/docs/torque/architecture.md create mode 100644 deps/v8/docs/torque/user-manual.md create mode 100644 deps/v8/docs/trace.md create mode 100644 deps/v8/docs/triage-issues.md create mode 100644 deps/v8/docs/untrusted-code-mitigations.md create mode 100644 deps/v8/docs/version-numbers.md create mode 100644 deps/v8/docs/viewer/.gitignore create mode 100644 deps/v8/docs/viewer/generator.js create mode 100644 deps/v8/docs/viewer/index.html create mode 100644 deps/v8/docs/viewer/package-lock.json create mode 100644 deps/v8/docs/viewer/package.json create mode 100644 deps/v8/docs/viewer/server.js create mode 100644 deps/v8/docs/wasm-shipping-checklist.md create mode 100644 deps/v8/docs/wasm/architecture.md create mode 100644 deps/v8/docs/webassembly-opcode.md create mode 100644 deps/v8/gni/cluster_build.gni delete mode 100644 deps/v8/gni/release_branch_toggle.gni delete mode 100644 deps/v8/src/base/cpu.cc create mode 100644 deps/v8/src/base/cpu/cpu-arm.cc create mode 100644 deps/v8/src/base/cpu/cpu-helper.h create mode 100644 deps/v8/src/base/cpu/cpu-loong64.cc create mode 100644 deps/v8/src/base/cpu/cpu-mips64.cc create mode 100644 deps/v8/src/base/cpu/cpu-ppc.cc create mode 100644 deps/v8/src/base/cpu/cpu-riscv.cc rename deps/v8/{test/mjsunit/debug-trace-minimal-in-print.js => src/base/cpu/cpu-s390.cc} (52%) create mode 100644 deps/v8/src/base/cpu/cpu-x86.cc create mode 100644 deps/v8/src/base/cpu/cpu.cc rename deps/v8/src/base/{ => cpu}/cpu.h (64%) create mode 100644 deps/v8/src/bigint/bigint-inl.h delete mode 100644 deps/v8/src/bigint/bitwise.cc delete mode 100644 deps/v8/src/bigint/digit-arithmetic.h create mode 100644 deps/v8/src/bigint/div-helpers-inl.h delete mode 100644 deps/v8/src/bigint/div-helpers.cc delete mode 100644 deps/v8/src/bigint/div-helpers.h delete mode 100644 deps/v8/src/bigint/mul-schoolbook.cc create mode 100644 deps/v8/src/bigint/vector-arithmetic-inl.h delete mode 100644 deps/v8/src/bigint/vector-arithmetic.cc delete mode 100644 deps/v8/src/bigint/vector-arithmetic.h create mode 100644 deps/v8/src/builtins/generator.tq delete mode 100644 deps/v8/src/builtins/js-to-js.tq create mode 100644 deps/v8/src/builtins/superspread.h create mode 100644 deps/v8/src/builtins/wasm-interpreter-wrappers.tq create mode 100644 deps/v8/src/codegen/riscv/constant-riscv-zfa.h create mode 100644 deps/v8/src/codegen/riscv/extension-riscv-zfa.cc create mode 100644 deps/v8/src/codegen/riscv/extension-riscv-zfa.h create mode 100644 deps/v8/src/compiler/backend/block-position.cc create mode 100644 deps/v8/src/compiler/backend/block-position.h delete mode 100644 deps/v8/src/compiler/pair-load-store-reducer.cc delete mode 100644 deps/v8/src/compiler/pair-load-store-reducer.h delete mode 100644 deps/v8/src/compiler/string-builder-optimizer.cc delete mode 100644 deps/v8/src/compiler/string-builder-optimizer.h rename deps/v8/src/compiler/turboshaft/{store-store-elimination-phase.cc => load-elimination-phase.cc} (66%) rename deps/v8/src/compiler/turboshaft/{optimize-phase.h => load-elimination-phase.h} (59%) rename deps/v8/src/compiler/turboshaft/{optimize-phase.cc => memory-optimization-phase.cc} (92%) rename deps/v8/src/compiler/turboshaft/{store-store-elimination-phase.h => memory-optimization-phase.h} (56%) rename deps/v8/src/{wasm/wrappers-inl.h => compiler/turboshaft/wasm-wrappers-inl.h} (61%) create mode 100644 deps/v8/src/compiler/turboshaft/wasm-wrappers.cc rename deps/v8/src/{wasm/wrappers.h => compiler/turboshaft/wasm-wrappers.h} (69%) delete mode 100644 deps/v8/src/extensions/ignition-statistics-extension.cc delete mode 100644 deps/v8/src/extensions/ignition-statistics-extension.h create mode 100644 deps/v8/src/inspector/SECURITY.md create mode 100644 deps/v8/src/maglev/maglev-map-inference.h create mode 100644 deps/v8/src/maglev/maglev-tracer.h delete mode 100644 deps/v8/src/objects/cpp-heap-external-object-inl.h create mode 100644 deps/v8/src/objects/feedback-transition-table.cc create mode 100644 deps/v8/src/objects/js-data-object-builder-inl.h create mode 100644 deps/v8/src/objects/js-data-object-builder.cc create mode 100644 deps/v8/src/objects/js-data-object-builder.h create mode 100644 deps/v8/src/objects/map-word-inl.h create mode 100644 deps/v8/src/objects/map-word.h create mode 100644 deps/v8/src/objects/object-predicates-inl.h create mode 100644 deps/v8/src/objects/object-predicates.h create mode 100644 deps/v8/src/objects/sort-state.h delete mode 100644 deps/v8/src/profiler/heap-snapshot-generator-inl.h create mode 100644 deps/v8/src/profiler/output-stream-writer.cc delete mode 100644 deps/v8/src/sandbox/code-pointer-inl.h delete mode 100644 deps/v8/src/sandbox/code-pointer.h create mode 100644 deps/v8/src/sandbox/trap-fuzzer.cc create mode 100644 deps/v8/src/sandbox/trap-fuzzer.h create mode 100644 deps/v8/src/wasm/effect-handler.h delete mode 100644 deps/v8/src/wasm/object-access.h create mode 100644 deps/v8/src/wasm/wasm-engine-globals.h delete mode 100644 deps/v8/src/wasm/wrappers.cc delete mode 100644 deps/v8/test/benchmarks/csuite/README.md delete mode 100755 deps/v8/test/benchmarks/csuite/benchmark.py delete mode 100755 deps/v8/test/benchmarks/csuite/compare-baseline.py delete mode 100755 deps/v8/test/benchmarks/csuite/csuite.py delete mode 100644 deps/v8/test/benchmarks/csuite/run-kraken.js delete mode 100644 deps/v8/test/benchmarks/csuite/sunspider-standalone-driver.js delete mode 100644 deps/v8/test/cctest/compiler/test-run-machops-select-loong64.cc delete mode 100644 deps/v8/test/cctest/test-ignition-statistics-extension.cc create mode 100644 deps/v8/test/debugger/regress/regress-483851884.js create mode 100644 deps/v8/test/debugger/regress/regress-485683107.js create mode 100644 deps/v8/test/debugger/regress/regress-486383560.js create mode 100644 deps/v8/test/debugger/regress/regress-488130830.js create mode 100644 deps/v8/test/filecheck/js-wasm-wrapper-inlining-eager-deopt.js create mode 100644 deps/v8/test/filecheck/js-wasm-wrapper-inlining-type-combos.js create mode 100644 deps/v8/test/filecheck/wasm-deopt-with-import.js create mode 100644 deps/v8/test/filecheck/wasm-in-js-inlining-turboshaft-stacktrace-api.js create mode 100644 deps/v8/test/filecheck/wasm-in-js-inlining-turboshaft.js create mode 100644 deps/v8/test/filecheck/wasm/crash/regress-481074858.js create mode 100644 deps/v8/test/filecheck/wasm/turbofan-extern-convert-any-dynamic.js create mode 100644 deps/v8/test/filecheck/wasm/turbofan-extern-convert-any-static.js create mode 100644 deps/v8/test/inspector/console/destroy-context-during-log-error-stack-expected.txt create mode 100644 deps/v8/test/inspector/console/destroy-context-during-log-error-stack.js create mode 100644 deps/v8/test/inspector/debugger/regress-crbug-503553614-expected.txt create mode 100644 deps/v8/test/inspector/debugger/regress-crbug-503553614.js create mode 100644 deps/v8/test/inspector/debugger/set-breakpoint-by-url-in-broken-script-expected.txt create mode 100644 deps/v8/test/inspector/debugger/set-breakpoint-by-url-in-broken-script.js create mode 100644 deps/v8/test/inspector/debugger/set-variable-value-oob-expected.txt create mode 100644 deps/v8/test/inspector/debugger/set-variable-value-oob.js create mode 100644 deps/v8/test/inspector/devtools-session.cc create mode 100644 deps/v8/test/inspector/devtools-session.h create mode 100644 deps/v8/test/inspector/regress/regress-crbug-486927780-expected.txt create mode 100644 deps/v8/test/inspector/regress/regress-crbug-486927780.js create mode 100644 deps/v8/test/inspector/regress/regress-crbug-488754138-expected.txt create mode 100644 deps/v8/test/inspector/regress/regress-crbug-488754138.js create mode 100644 deps/v8/test/inspector/regress/regress-crbug-502724368-expected.txt create mode 100644 deps/v8/test/inspector/regress/regress-crbug-502724368.js create mode 100644 deps/v8/test/inspector/regress/regress-crbug-516311623-expected.txt create mode 100644 deps/v8/test/inspector/regress/regress-crbug-516311623.js create mode 100644 deps/v8/test/inspector/runtime/regress-488790217-expected.txt create mode 100644 deps/v8/test/inspector/runtime/regress-488790217.js create mode 100644 deps/v8/test/inspector/runtime/regress-517981277-expected.txt create mode 100644 deps/v8/test/inspector/runtime/regress-517981277.js delete mode 100644 deps/v8/test/intl/number-format/comma-compat-off.js delete mode 100644 deps/v8/test/intl/number-format/comma-compat-on.js delete mode 100644 deps/v8/test/intl/number-format/italian-compat-off.js delete mode 100644 deps/v8/test/intl/number-format/italian-compat-on.js create mode 100644 deps/v8/test/message/fail/iterator-zip-return-error.js create mode 100644 deps/v8/test/message/fail/iterator-zip-return-error.out create mode 100644 deps/v8/test/message/fail/regress-tdz-closure.js create mode 100644 deps/v8/test/message/fail/regress-tdz-closure.out delete mode 100644 deps/v8/test/message/wasm-in-js-inlining-turboshaft.js delete mode 100644 deps/v8/test/message/wasm-in-js-inlining-turboshaft.out create mode 100644 deps/v8/test/mjsunit/arbitrary-length-varargs.js create mode 100644 deps/v8/test/mjsunit/array-flat-elements-kind.js create mode 100644 deps/v8/test/mjsunit/array-sort-inline.js create mode 100644 deps/v8/test/mjsunit/array-sort-stability.js create mode 100644 deps/v8/test/mjsunit/compiler/no-fma.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-488078904.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-488925413.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-498818400.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-499319121.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-504073873.js create mode 100644 deps/v8/test/mjsunit/compiler/regress-505823721.js create mode 100644 deps/v8/test/mjsunit/d8-builtins-not-constructors.js create mode 100644 deps/v8/test/mjsunit/d8/cwd/working_dir.js create mode 100644 deps/v8/test/mjsunit/d8/cwd/working_dir_helper.js.skip create mode 100644 deps/v8/test/mjsunit/d8/cwd/working_dir_test.js.skip create mode 100644 deps/v8/test/mjsunit/d8/d8-realm-onerror.js create mode 100644 deps/v8/test/mjsunit/d8/d8-worker-onerror-arguments.js create mode 100644 deps/v8/test/mjsunit/d8/d8-worker-onerror-exception.js create mode 100644 deps/v8/test/mjsunit/d8/d8-worker-onerror-settimeout.js create mode 100644 deps/v8/test/mjsunit/d8/d8-worker-onerror.js create mode 100644 deps/v8/test/mjsunit/d8/files/exists.js create mode 100644 deps/v8/test/mjsunit/d8/module-bundle-1.js create mode 100644 deps/v8/test/mjsunit/d8/module-bundle-2.js create mode 100644 deps/v8/test/mjsunit/d8/module-bundle-dynamic-import-https.js create mode 100644 deps/v8/test/mjsunit/d8/regress-503488299.js create mode 100644 deps/v8/test/mjsunit/d8/script-bundle.js create mode 100644 deps/v8/test/mjsunit/d8_trace.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-eager-check-missing-done.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-eager-check.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-eager-next-call.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-eager-value-check.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-lazy-check.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-lazy-next-call.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-array-iterator-optimization-maglev-lazy-value-check.js create mode 100644 deps/v8/test/mjsunit/es6/for-of-iterator-protocol-integrity.js create mode 100644 deps/v8/test/mjsunit/es6/weak-map-chain-linear.js create mode 100644 deps/v8/test/mjsunit/es6/weak-map-chain-nested-linear.js create mode 100644 deps/v8/test/mjsunit/harmony/iterator-zip-keyed.js create mode 100644 deps/v8/test/mjsunit/harmony/iterator-zip.js create mode 100644 deps/v8/test/mjsunit/harmony/modules-import-defer-asm.mjs create mode 100644 deps/v8/test/mjsunit/harmony/modules-import-defer-prototype-swap-for-in-that-throws.mjs create mode 100644 deps/v8/test/mjsunit/harmony/modules-import-defer-prototype-swap-for-in.mjs create mode 100644 deps/v8/test/mjsunit/harmony/modules-import-defer-super-property-set-exported.mjs create mode 100644 deps/v8/test/mjsunit/harmony/modules-import-defer-super-property-set-not-exported.mjs create mode 100644 deps/v8/test/mjsunit/harmony/modules-namespace-asm.mjs create mode 100644 deps/v8/test/mjsunit/harmony/regress/regress-499254994.js create mode 100644 deps/v8/test/mjsunit/harmony/regress/regress-499254996.mjs create mode 100644 deps/v8/test/mjsunit/homomorphic-array-smi.js create mode 100644 deps/v8/test/mjsunit/homomorphic-ic.js create mode 100644 deps/v8/test/mjsunit/iterator-join.js create mode 100644 deps/v8/test/mjsunit/json-simd-strings.js create mode 100644 deps/v8/test/mjsunit/maglev/array-push-int32-phi.js create mode 100644 deps/v8/test/mjsunit/maglev/boolean-constructor.js create mode 100644 deps/v8/test/mjsunit/maglev/context-inverted-generator.js create mode 100644 deps/v8/test/mjsunit/maglev/context-inverted-generator2.js create mode 100644 deps/v8/test/mjsunit/maglev/maglev-508811474.js create mode 100644 deps/v8/test/mjsunit/maglev/reflect-apply.js create mode 100644 deps/v8/test/mjsunit/maglev/reflect-get.js create mode 100644 deps/v8/test/mjsunit/maglev/reflect-has.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-470566252.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-482545639.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-482810539.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-483423907.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-484393248.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-484911060.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-485843940.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-486530209.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-489362238.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-489369253.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-490353576.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-492245079.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-494492520.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-495041650.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-495751197.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-495888361.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-495923720.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-496074718.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-496272034.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-496627235.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-497112471.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-497831280.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-498199197.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-498816446-1.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-498816446-2.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-498816446-3.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-499752800.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-500174840.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-500177421.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-500193083.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-500507435.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-500774816.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-501676158.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-503197484.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-503977642.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-505413738-1.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-505413738-2.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-513350759.js create mode 100644 deps/v8/test/mjsunit/maglev/regress-523884658.js create mode 100644 deps/v8/test/mjsunit/maglev/regress/regress-489605205.js create mode 100644 deps/v8/test/mjsunit/maglev/string-indexof-includes.js create mode 100644 deps/v8/test/mjsunit/maglev/string-substring.js create mode 100644 deps/v8/test/mjsunit/maglev/uint8-clamped-store-undefined.js create mode 100644 deps/v8/test/mjsunit/maglev/unused-loop-phi.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/closing.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/holey.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/holey2.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/regress-494013010.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/regress-sumPrecise-iterator.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/set-iterator-clear-on-error.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/set-regress.js create mode 100644 deps/v8/test/mjsunit/math-sum-precise/set-regress2.js create mode 100644 deps/v8/test/mjsunit/modules-eval-await.mjs create mode 100644 deps/v8/test/mjsunit/modules-namespace-super-access-tdz.mjs create mode 100644 deps/v8/test/mjsunit/modules-namespace-super-property-set.mjs create mode 100644 deps/v8/test/mjsunit/modules-namespace-super-set-tdz-with-accessor.mjs create mode 100644 deps/v8/test/mjsunit/modules-skip-star-exports-indirect-cycle-a.mjs create mode 100644 deps/v8/test/mjsunit/modules-skip-star-exports-indirect-cycle-b.mjs create mode 100644 deps/v8/test/mjsunit/modules-skip-star-exports-indirect-cycle-c.mjs create mode 100644 deps/v8/test/mjsunit/modules-skip-star-exports-indirect-cycle-d.mjs create mode 100644 deps/v8/test/mjsunit/modules-star-exports-indirect-cycle.mjs create mode 100644 deps/v8/test/mjsunit/private_fields/test_private_fields.js create mode 100644 deps/v8/test/mjsunit/queue-microtask-cross-realm-callback-report-exception.js create mode 100644 deps/v8/test/mjsunit/queue-microtask.js create mode 100644 deps/v8/test/mjsunit/regress-478205262.js create mode 100644 deps/v8/test/mjsunit/regress-491935269.js create mode 100644 deps/v8/test/mjsunit/regress-493787228.js create mode 100644 deps/v8/test/mjsunit/regress-494876356.js create mode 100644 deps/v8/test/mjsunit/regress-507036687.js create mode 100644 deps/v8/test/mjsunit/regress-module-export-proto-helper.mjs create mode 100644 deps/v8/test/mjsunit/regress-module-export-proto.mjs create mode 100644 deps/v8/test/mjsunit/regress/asm/regress-490629397.js create mode 100644 deps/v8/test/mjsunit/regress/immutable-ab-regress.js create mode 100644 deps/v8/test/mjsunit/regress/regexp-489358153.js delete mode 100644 deps/v8/test/mjsunit/regress/regress-1000635.js create mode 100644 deps/v8/test/mjsunit/regress/regress-435589244.js create mode 100644 deps/v8/test/mjsunit/regress/regress-462795139.js create mode 100644 deps/v8/test/mjsunit/regress/regress-476509600.js create mode 100644 deps/v8/test/mjsunit/regress/regress-481519344.js create mode 100644 deps/v8/test/mjsunit/regress/regress-484904778.js create mode 100644 deps/v8/test/mjsunit/regress/regress-486655252.js create mode 100644 deps/v8/test/mjsunit/regress/regress-486945364-1.js create mode 100644 deps/v8/test/mjsunit/regress/regress-486945364.js create mode 100644 deps/v8/test/mjsunit/regress/regress-487468464.js create mode 100644 deps/v8/test/mjsunit/regress/regress-487857171.js create mode 100644 deps/v8/test/mjsunit/regress/regress-488042855.js create mode 100644 deps/v8/test/mjsunit/regress/regress-489356185.js create mode 100644 deps/v8/test/mjsunit/regress/regress-489941769.js create mode 100644 deps/v8/test/mjsunit/regress/regress-490446682.js create mode 100644 deps/v8/test/mjsunit/regress/regress-490485402.js create mode 100644 deps/v8/test/mjsunit/regress/regress-490515529.js create mode 100644 deps/v8/test/mjsunit/regress/regress-490640045.js create mode 100644 deps/v8/test/mjsunit/regress/regress-491053452.js create mode 100644 deps/v8/test/mjsunit/regress/regress-491461591.js create mode 100644 deps/v8/test/mjsunit/regress/regress-491881374.js create mode 100644 deps/v8/test/mjsunit/regress/regress-492014648.js create mode 100644 deps/v8/test/mjsunit/regress/regress-493176399.js create mode 100644 deps/v8/test/mjsunit/regress/regress-493269623.js create mode 100644 deps/v8/test/mjsunit/regress/regress-493591676.mjs create mode 100644 deps/v8/test/mjsunit/regress/regress-493787222.js create mode 100644 deps/v8/test/mjsunit/regress/regress-494388373.js create mode 100644 deps/v8/test/mjsunit/regress/regress-494583765.js create mode 100644 deps/v8/test/mjsunit/regress/regress-494690599.js create mode 100644 deps/v8/test/mjsunit/regress/regress-495503057.mjs create mode 100644 deps/v8/test/mjsunit/regress/regress-495503781.js create mode 100644 deps/v8/test/mjsunit/regress/regress-498010834.js create mode 100644 deps/v8/test/mjsunit/regress/regress-498089319-2.js create mode 100644 deps/v8/test/mjsunit/regress/regress-498089319.js create mode 100644 deps/v8/test/mjsunit/regress/regress-498464176.js create mode 100644 deps/v8/test/mjsunit/regress/regress-498904299.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499260582.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499323105.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499527555-2.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499527555.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499659062.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499667401.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499672315.js create mode 100644 deps/v8/test/mjsunit/regress/regress-499721612.js create mode 100644 deps/v8/test/mjsunit/regress/regress-500174491.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501224234-ignition.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501224234-maglev.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501224234-minimized.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501224234-turbofan.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501464526.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501749462-ic.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501749462-maglev.js create mode 100644 deps/v8/test/mjsunit/regress/regress-501749462.js create mode 100644 deps/v8/test/mjsunit/regress/regress-502244656.js create mode 100644 deps/v8/test/mjsunit/regress/regress-502439789.js create mode 100644 deps/v8/test/mjsunit/regress/regress-503097371.js create mode 100644 deps/v8/test/mjsunit/regress/regress-503634281.js create mode 100644 deps/v8/test/mjsunit/regress/regress-504490097.js create mode 100644 deps/v8/test/mjsunit/regress/regress-505101417.js create mode 100644 deps/v8/test/mjsunit/regress/regress-505116710.js create mode 100644 deps/v8/test/mjsunit/regress/regress-505481956.js create mode 100644 deps/v8/test/mjsunit/regress/regress-505551322.js create mode 100644 deps/v8/test/mjsunit/regress/regress-506617613.js create mode 100644 deps/v8/test/mjsunit/regress/regress-506855825.js create mode 100644 deps/v8/test/mjsunit/regress/regress-507671690.js create mode 100644 deps/v8/test/mjsunit/regress/regress-509268941-2.js create mode 100644 deps/v8/test/mjsunit/regress/regress-509312809.js create mode 100644 deps/v8/test/mjsunit/regress/regress-513936340.js create mode 100644 deps/v8/test/mjsunit/regress/regress-522126182.js create mode 100644 deps/v8/test/mjsunit/regress/regress-7558019.js delete mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-335704358.js delete mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-42213031.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-488366773.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-488426618.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-489893167.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-490058830.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-502439789.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-502832780.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-502923583.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-502944996-b.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-502944996.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503098806.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503180648.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503557995-b.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503557995.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503615221.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-503622403.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-504070398.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-506689381.js create mode 100644 deps/v8/test/mjsunit/regress/regress-temporal-zoneinfo.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-391907159.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-482759504.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-483269968.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-483643012.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-484405356.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-484499097.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-487444465.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-487750545.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-488089242.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-488790214.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-488943662.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-489029655.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-489109716.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-489349562.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-490183533.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-490877756.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-490877757.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-490877758.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-490970052.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-491696923.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493088266.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493099941.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493171989.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493197128.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493307331.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493314948.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493319628.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493430818.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493521637.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493521807.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493529579.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493646648.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-493905761.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-495503265.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-496628168.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-497330272.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-497404188.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-498709150.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-498814570.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-498818401.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-499150024.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-499492236.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-500113958.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-500171779.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-500181839.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-500890918.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-501198834.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-502030575.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-502287689.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-502300817.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-502624513.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-504612573.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-504708686.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-504711585.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-504714846.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-504716006.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-505117973.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-505124865.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-505481948.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-505858818.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-509268941-1.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-509268941.js delete mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-crbug-1006631.js delete mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-crbug-1047368.js delete mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-crbug-1463219.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-simd-507671691.js create mode 100644 deps/v8/test/mjsunit/regress/wasm/regress-simd-508025392.js create mode 100644 deps/v8/test/mjsunit/sandbox/hardware-watchpoints/double-registers-double-watchpoint.js create mode 100644 deps/v8/test/mjsunit/sandbox/hardware-watchpoints/double-registers.js create mode 100644 deps/v8/test/mjsunit/sandbox/hardware-watchpoints/duplicate-watchpoint.js create mode 100644 deps/v8/test/mjsunit/sandbox/hardware-watchpoints/regress-486705321.js create mode 100644 deps/v8/test/mjsunit/sandbox/hardware-watchpoints/regress-496855012.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-488362583.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-488651088.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-488927521.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-490769268.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-496618662.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-496807861.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-499717570.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-501147587.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-502356099.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress-getparameter.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress/regress-496341820.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress/regress-501115746.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress/regress-501626906.js create mode 100644 deps/v8/test/mjsunit/sandbox/regress/regress-502337304.js create mode 100644 deps/v8/test/mjsunit/sandbox/wasmfx-signature-check.js create mode 100644 deps/v8/test/mjsunit/shared-memory/regress-488754149.js create mode 100644 deps/v8/test/mjsunit/tools/v8-logviewer-args.mjs create mode 100644 deps/v8/test/mjsunit/turbolev/regress-479549166.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-482084211.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-484527367.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-485478594.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-485535276.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-487646536.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-488090094.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-488790215.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-489193276.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-489689984.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-490450922-1.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-490450922-2.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-490450922-3.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-491466705.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-492046462.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-493319584.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-493534950.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-494058284.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-498813012.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-499934837.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-503975738-1.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-503975738-2.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-505610970.js create mode 100644 deps/v8/test/mjsunit/turbolev/regress-506060820.js create mode 100644 deps/v8/test/mjsunit/turbolev/super-try-catch-derived-constructor.js create mode 100644 deps/v8/test/mjsunit/turboshaft/regress-508347351.js create mode 100644 deps/v8/test/mjsunit/turboshaft/regress-527385397.js create mode 100644 deps/v8/test/mjsunit/typedarray-with-resizable-buffer.js create mode 100644 deps/v8/test/mjsunit/wasm/call-indirect-null-check.js create mode 100644 deps/v8/test/mjsunit/wasm/compact-imports.js create mode 100644 deps/v8/test/mjsunit/wasm/compile-time-builtins.js create mode 100644 deps/v8/test/mjsunit/wasm/custom-descriptors-boundary.js create mode 100644 deps/v8/test/mjsunit/wasm/custom-descriptors-oom.js delete mode 100644 deps/v8/test/mjsunit/wasm/exceptions-type-reflection.js create mode 100644 deps/v8/test/mjsunit/wasm/load-shift32.js create mode 100644 deps/v8/test/mjsunit/wasm/quarter-shuffles.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-496645739.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-497667917.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-498482620.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-499719427.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-522454846.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-dataview-immutable.js create mode 100644 deps/v8/test/mjsunit/wasm/regress-wasmfx-exact-types.js rename deps/v8/test/mjsunit/wasm/shared-everything/{test-acq-rel-instructions.js => acq-rel-load-and-store.js} (100%) create mode 100644 deps/v8/test/mjsunit/wasm/shared-everything/acq-rel-rmw-operations.js create mode 100644 deps/v8/test/mjsunit/wasm/shared-everything/string-builtins-utf8.js create mode 100644 deps/v8/test/mjsunit/wasm/shared-everything/string-builtins.js create mode 100644 deps/v8/test/mjsunit/wasm/shared-everything/strings.js create mode 100644 deps/v8/test/mjsunit/wasm/shared-everything/wait-queue.js create mode 100644 deps/v8/test/mjsunit/wasm/simd-reduce.js create mode 100644 deps/v8/test/mjsunit/wasm/simd-replace-lane-zero.js create mode 100644 deps/v8/test/mjsunit/wasm/simd-rot64-no-xor.js create mode 100644 deps/v8/test/mjsunit/wasm/simd-xor-rot64.js create mode 100644 deps/v8/test/mjsunit/wasm/stack-switching-argswitch.js create mode 100644 deps/v8/test/mjsunit/wasm/stack-switching-no-cont-leak.js create mode 100644 deps/v8/test/mjsunit/wasm/stack-switching-switch-loop.js create mode 100644 deps/v8/test/mjsunit/wasm/stack-switching-switch.js delete mode 100644 deps/v8/test/mjsunit/wasm/type-reflection-exnref.js delete mode 100644 deps/v8/test/mjsunit/wasm/type-reflection.js create mode 100644 deps/v8/test/mjsunit/wasm/wasm-wrapper-inlining-turbolev.js create mode 100644 deps/v8/test/mjsunit/wasm/wasmfx-load-elimination.js create mode 100644 deps/v8/test/mjsunit/wasm/wide-arithmetic.js create mode 100644 deps/v8/test/mjsunit/wasm/wrapper-inlining-lazy-deopt-turbolev.js delete mode 100644 deps/v8/test/test262/local-tests/test/staging/built-ins/RegExp/escape/surrogate-pair.js create mode 100644 deps/v8/test/unittests/base/asan-unittest.cc create mode 100644 deps/v8/test/unittests/codegen/safepoint-table-unittest.cc create mode 100644 deps/v8/test/unittests/compiler/turboshaft/machine-optimization-reducer-unittest.cc create mode 100644 deps/v8/test/unittests/heap/cppgc-js/cpp-heap-stack-start-marker-unittest.cc create mode 100644 deps/v8/test/unittests/heap/cppgc/stack-start-marker-unittest.cc create mode 100644 deps/v8/test/unittests/heap/minimal-stack-unittest.cc create mode 100644 deps/v8/test/unittests/interpreter/bytecode_expectations/HoleCheckElision.golden create mode 100644 deps/v8/test/unittests/interpreter/bytecode_expectations/PrivateFieldSpecializedBytecode.golden create mode 100644 deps/v8/test/unittests/objects/module-request-unittest.cc create mode 100644 deps/v8/test/unittests/profiler/heap-snapshot-utils.cc create mode 100644 deps/v8/test/unittests/profiler/heap-snapshot-utils.h create mode 100644 deps/v8/test/unittests/sandbox/libcxx-hardening-unittest.cc create mode 100644 deps/v8/test/unittests/sandbox/trap-fuzzer-unittest.cc create mode 100644 deps/v8/test/webkit/fast/js/nested-object-gc-expected.txt create mode 100644 deps/v8/test/webkit/fast/js/nested-object-gc.js create mode 100644 deps/v8/third_party/abseil-cpp/absl/base/internal/hardening.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/base/internal/hardening.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/base/internal/hardening_test.cc rename deps/v8/third_party/abseil-cpp/absl/base/{internal => }/throw_delegate.cc (93%) rename deps/v8/third_party/abseil-cpp/absl/base/{internal => }/throw_delegate.h (81%) delete mode 100644 deps/v8/third_party/abseil-cpp/absl/debugging/internal/borrowed_fixup_buffer.cc delete mode 100644 deps/v8/third_party/abseil-cpp/absl/debugging/internal/borrowed_fixup_buffer.h delete mode 100644 deps/v8/third_party/abseil-cpp/absl/debugging/internal/borrowed_fixup_buffer_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/random/mocking_access.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/strings/internal/stringify_stream.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/strings/internal/stringify_stream_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/clock_interface.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/clock_interface.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/clock_interface_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/simulated_clock.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/simulated_clock.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/time/simulated_clock_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/any_span.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/any_span_benchmark.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/any_span_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/internal/any_span.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/optional_ref.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/optional_ref_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/source_location.cc create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/source_location.h create mode 100644 deps/v8/third_party/abseil-cpp/absl/types/source_location_test.cc create mode 100644 deps/v8/third_party/abseil-cpp/patches/0007-deprecated-base64-escape.patch create mode 100644 deps/v8/third_party/abseil-cpp/patches/0008-deprecated-meta-type-traits.patch create mode 100644 deps/v8/third_party/abseil-cpp/patches/0009-keep-random-internal-transitive-includes.patch create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/algo/count-inl.h create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/algo/count_value_test.cc create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/algo/minmax-inl.h create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/algo/minmax_value_test.cc create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/math/fast_math-inl.h create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/math/math_benchmark.cc create mode 100644 deps/v8/third_party/highway/src/hwy/contrib/thread_pool/thread_pool.cc create mode 100644 deps/v8/third_party/highway/src/hwy/examples/README.md create mode 100644 deps/v8/third_party/highway/src/hwy/examples/sum_array_advanced.cc create mode 100644 deps/v8/third_party/highway/src/hwy/examples/sum_array_simple.cc create mode 100644 deps/v8/third_party/highway/src/hwy/tests/compare_128_test.cc create mode 100644 deps/v8/third_party/highway/src/hwy/tests/masked_compare_test.cc create mode 100644 deps/v8/third_party/highway/src/hwy/tests/neg_test.cc create mode 100644 deps/v8/third_party/v8/builtins/array-sort.h create mode 100644 deps/v8/third_party/zlib/README create mode 100644 deps/v8/third_party/zlib/doc/algorithm.txt create mode 100644 deps/v8/third_party/zlib/doc/crc-doc.1.0.pdf create mode 100644 deps/v8/third_party/zlib/doc/rfc1950.txt create mode 100644 deps/v8/third_party/zlib/doc/rfc1951.txt create mode 100644 deps/v8/third_party/zlib/doc/rfc1952.txt create mode 100644 deps/v8/third_party/zlib/doc/txtvsbin.txt delete mode 100644 deps/v8/third_party/zlib/patches/0010-cmake-enable-simd.patch create mode 100644 deps/v8/third_party/zlib/patches/0010-cmake.patch create mode 100644 deps/v8/third_party/zlib/patches/0019-fix-zip64-in-zip.patch create mode 100644 deps/v8/third_party/zlib/win32/zlib1.rc delete mode 100644 deps/v8/third_party/zlib/zconf.h.cmakein create mode 100644 deps/v8/third_party/zlib/zlibConfig.cmake.in create mode 100644 deps/v8/tools/cluster_files.py create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/mutators/memory_corruption_mutator.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/resources/sandbox_fuzz_library.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test/test_memory_corruptions.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/memory_corruption/input.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/memory_corruption/output_expected.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/regress/await/db/AwaitExpression/a1.json create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/regress/await/db/index.json create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/regress/await/expected.js create mode 100644 deps/v8/tools/clusterfuzz/js_fuzzer/test_data/regress/await/input.js create mode 100755 deps/v8/tools/clusterfuzz/js_fuzzer/tools/run_locally_against_d8.py create mode 100755 deps/v8/tools/dev/setup_worktree_build.py create mode 100755 deps/v8/tools/find-d8.sh create mode 100644 deps/v8/tools/system-analyzer/cli.mjs create mode 100644 deps/v8/tools/testrunner/testproc/indicators_test.py create mode 100755 deps/v8/tools/turboshaft-stacktrace-filter.py create mode 100644 deps/v8/tools/turboshaft_type_formatter.py create mode 100755 deps/v8/tools/v8-logviewer diff --git a/deps/v8/.git-blame-ignore-revs b/deps/v8/.git-blame-ignore-revs index 0b12c1ac601857..98275bc6748f9a 100644 --- a/deps/v8/.git-blame-ignore-revs +++ b/deps/v8/.git-blame-ignore-revs @@ -124,3 +124,6 @@ cb67be1a3842fcf6a0da18aee444e3b7ea789e04 d1b27019d3bf86360ea838c317f8505fac6d3a7e 44fe02ced6e4c6b49d627807e3b3fd0edbbeb36e ec06bb6ce5641cf65e400ec55b7421f87d04b999 + +# Simplify variants flags +0476eb39b3c58671720d3ef78730821a5b7d93fa diff --git a/deps/v8/.gitignore b/deps/v8/.gitignore index 240c287763ca99..2a420b8147227e 100644 --- a/deps/v8/.gitignore +++ b/deps/v8/.gitignore @@ -40,6 +40,8 @@ .settings .torquelint-cache .vscode +.agents +.gemini # Directories added by standalone gclient setup. /.cipd @@ -62,6 +64,7 @@ /src/inspector/build/closure-compiler /src/inspector/build/closure-compiler.tar.gz /test/benchmarks/data +/test/benchmarks/JetStream3 /test/fuzzer/wasm_corpus/ /test/fuzzer/wasm_corpus.tar.gz !/test/mjsunit/tools/*.log @@ -156,6 +159,8 @@ bazel-testlogs bazel-v8 launch.json MODULE.bazel.lock +GEMINI.md +AGENTS.md !/third_party/jinja2 !/third_party/markupsafe !/third_party/zlib diff --git a/deps/v8/.gn b/deps/v8/.gn index 6ead7196c515cf..8b788bd17722d1 100644 --- a/deps/v8/.gn +++ b/deps/v8/.gn @@ -43,6 +43,8 @@ default_args = { # These are the list of GN files that run exec_script. This whitelist exists # to force additional review for new uses of exec_script, which is strongly -# discouraged except for gypi_to_gn calls. -exec_script_allowlist = build_dotfile_settings.exec_script_allowlist + - [ "//build_overrides/build.gni" ] +# discouraged. +exec_script_allowlist = build_dotfile_settings.exec_script_allowlist + [ + "//build_overrides/build.gni", + "//gni/cluster_build.gni", + ] diff --git a/deps/v8/.vpython3 b/deps/v8/.vpython3 index 0d30d688efa997..8551fa2f7a1109 100644 --- a/deps/v8/.vpython3 +++ b/deps/v8/.vpython3 @@ -28,14 +28,14 @@ python_version: "3.11" # Setting `verify_pep425_tag` to the list of platforms we explicitly must support # allows us to ensure that vpython specs stay mac-arm64-friendly verify_pep425_tag: [ - {python: "cp38", abi: "cp38", platform: "manylinux1_x86_64"}, - {python: "cp38", abi: "cp38", platform: "linux_arm64"}, + {python: "cp311", abi: "cp311", platform: "manylinux1_x86_64"}, + {python: "cp311", abi: "cp311", platform: "linux_arm64"}, - {python: "cp38", abi: "cp38", platform: "macosx_10_10_intel"}, - {python: "cp38", abi: "cp38", platform: "macosx_11_0_arm64"}, + {python: "cp311", abi: "cp311", platform: "macosx_10_10_intel"}, + {python: "cp311", abi: "cp311", platform: "macosx_11_0_arm64"}, - {python: "cp38", abi: "cp38", platform: "win32"}, - {python: "cp38", abi: "cp38", platform: "win_amd64"} + {python: "cp311", abi: "cp311", platform: "win32"}, + {python: "cp311", abi: "cp311", platform: "win_amd64"} ] # TODO(https://crbug.com/898348): Add in necessary wheels as Python3 versions diff --git a/deps/v8/.ycm_extra_conf.py b/deps/v8/.ycm_extra_conf.py index c44d4ef09c0ef4..c6460adbe124b5 100644 --- a/deps/v8/.ycm_extra_conf.py +++ b/deps/v8/.ycm_extra_conf.py @@ -63,14 +63,12 @@ def FindV8SrcFromFilename(filename): (String) Path of 'v8/', or None if unable to find. """ curdir = os.path.normpath(os.path.dirname(filename)) - while not (PathExists(curdir, 'v8') and PathExists(curdir, 'v8', 'DEPS') - and (PathExists(curdir, '.gclient') - or PathExists(curdir, 'v8', '.git'))): + while not PathExists(curdir, '.git'): nextdir = os.path.normpath(os.path.join(curdir, '..')) if nextdir == curdir: return None curdir = nextdir - return os.path.join(curdir, 'v8') + return curdir def GetClangCommandFromNinjaForFilename(v8_root, filename): diff --git a/deps/v8/AUTHORS b/deps/v8/AUTHORS index 9329e34ae252be..fbb38cda6dc09d 100644 --- a/deps/v8/AUTHORS +++ b/deps/v8/AUTHORS @@ -44,6 +44,7 @@ Julia Computing, Inc. <*@juliacomputing.com> CodeWeavers, Inc. <*@codeweavers.com> Alibaba, Inc. <*@alibaba-inc.com> SiFive, Inc. <*@sifive.com> +Island Technology, Inc. <*@island.io> Aapo Alasuutari Aaron Bieber @@ -131,7 +132,7 @@ Fedor Indutny Felix Geisendörfer Feng Yu Filipe David Manana -Florian Loitsch +Florian Loitsch Frank Lemanschik Franziska Hinkelmann Gao Sheng @@ -163,9 +164,11 @@ Jaime Bernardo Jake Hughes James M Snell James Pike +Jamie Magee Jan Krems Jan de Mooij Janusz Majnert +Jarden Xian Javad Amiri Jay Freeman Jeroen Bobbeldijk @@ -187,7 +190,7 @@ Junha Park Junming Huang Kang-Hao (Kenny) Lu Karl Skomski -Kasper Lund +Kasper Lund Keith Smiley Kenta Moriuchi Kevin Gibbons @@ -238,6 +241,7 @@ Nicolas Antonius Ernst Leopold Maria Kaiser Nicolò Ribaudo Niek van der Maas Niklas Hambüchen +Niklas Wenzel Noj Vek Oleksandr Chekhovskyi Oliver Dunk diff --git a/deps/v8/BUILD.bazel b/deps/v8/BUILD.bazel index f28fea4e8aa162..b432f8649854f3 100644 --- a/deps/v8/BUILD.bazel +++ b/deps/v8/BUILD.bazel @@ -170,6 +170,11 @@ v8_flag( v8_flag(name = "v8_enable_experimental_tq_to_tsa") +v8_flag( + name = "v8_use_host_cpu_arm_features", + default = True, +) + # Default setting for v8_enable_maglev selects.config_setting_group( name = "maglev_by_default", @@ -521,6 +526,7 @@ v8_config( "v8_jitless": "V8_JITLESS", "v8_enable_vtunejit": "ENABLE_VTUNE_JIT_INTERFACE", "v8_enable_undefined_double": "V8_ENABLE_UNDEFINED_DOUBLE", + "v8_use_host_cpu_arm_features": "V8_USE_HOST_CPU_ARM_FEATURES", }, defines = [ "GOOGLE3", @@ -837,8 +843,9 @@ filegroup( "src/base/compiler-specific.h", "src/base/container-utils.h", "src/base/contextual.h", - "src/base/cpu.cc", - "src/base/cpu.h", + "src/base/cpu/cpu.cc", + "src/base/cpu/cpu.h", + "src/base/cpu/cpu-helper.h", "src/base/debug/stack_trace.cc", "src/base/debug/stack_trace.h", "src/base/discriminated-union.h", @@ -991,6 +998,25 @@ filegroup( "src/base/platform/platform-win32.h", "src/base/win32-headers.h", ], + }) + select({ + "@v8//bazel/config:v8_target_x64": [ + "src/base/cpu/cpu-x86.cc", + ], + "@v8//bazel/config:v8_target_ia32": [ + "src/base/cpu/cpu-x86.cc", + ], + "@v8//bazel/config:v8_target_arm64": [ + "src/base/cpu/cpu-arm.cc", + ], + "@v8//bazel/config:v8_target_arm": [ + "src/base/cpu/cpu-arm.cc", + ], + "@v8//bazel/config:v8_target_ppc64le": [ + "src/base/cpu/cpu-ppc.cc", + ], + "@v8//bazel/config:v8_target_riscv64": [ + "src/base/cpu/cpu-riscv.cc", + ], }), visibility = ["//visibility:public"], ) @@ -1092,6 +1118,7 @@ filegroup( "src/builtins/frame-arguments.tq", "src/builtins/frames.tq", "src/builtins/function.tq", + "src/builtins/generator.tq", "src/builtins/growable-fixed-array.tq", "src/builtins/ic.tq", "src/builtins/ic-callable.tq", @@ -1272,7 +1299,6 @@ filegroup( "third_party/v8/builtins/array-sort.tq", ] + select({ ":is_v8_enable_webassembly": [ - "src/builtins/js-to-js.tq", "src/builtins/js-to-wasm.tq", "src/builtins/wasm.tq", "src/builtins/wasm-strings.tq", @@ -1280,6 +1306,9 @@ filegroup( "src/debug/debug-wasm-objects.tq", "src/wasm/wasm-objects.tq", ], + ":is_v8_enable_drumbrake": [ + "src/wasm/wasm-interpreter-objects.tq" + ], "//conditions:default": [], }), ) @@ -1479,6 +1508,7 @@ filegroup( "src/builtins/constants-table-builder.h", "src/builtins/data-view-ops.h", "src/builtins/profile-data-reader.h", + "src/builtins/superspread.h", "src/codegen/aligned-slot-allocator.cc", "src/codegen/aligned-slot-allocator.h", "src/codegen/assembler.cc", @@ -1703,8 +1733,6 @@ filegroup( "src/extensions/externalize-string-extension.h", "src/extensions/gc-extension.cc", "src/extensions/gc-extension.h", - "src/extensions/ignition-statistics-extension.cc", - "src/extensions/ignition-statistics-extension.h", "src/extensions/statistics-extension.cc", "src/extensions/statistics-extension.h", "src/extensions/trigger-failure-extension.cc", @@ -2082,7 +2110,6 @@ filegroup( "src/objects/contexts.h", "src/objects/contexts-inl.h", "src/objects/cpp-heap-external-object.h", - "src/objects/cpp-heap-external-object-inl.h", "src/objects/cpp-heap-object-wrapper.h", "src/objects/cpp-heap-object-wrapper-inl.h", "src/objects/data-handler.h", @@ -2112,6 +2139,7 @@ filegroup( "src/objects/embedder-data-slot-inl.h", "src/objects/feedback-cell.h", "src/objects/feedback-cell-inl.h", + "src/objects/feedback-transition-table.cc", "src/objects/feedback-vector.cc", "src/objects/feedback-vector.h", "src/objects/feedback-vector-inl.h", @@ -2153,6 +2181,9 @@ filegroup( "src/objects/js-collection-inl.h", "src/objects/js-collection-iterator.h", "src/objects/js-collection-iterator-inl.h", + "src/objects/js-data-object-builder.cc", + "src/objects/js-data-object-builder.h", + "src/objects/js-data-object-builder-inl.h", "src/objects/js-disposable-stack.cc", "src/objects/js-disposable-stack.h", "src/objects/js-disposable-stack-inl.h", @@ -2211,6 +2242,8 @@ filegroup( "src/objects/map.cc", "src/objects/map.h", "src/objects/map-inl.h", + "src/objects/map-word.h", + "src/objects/map-word-inl.h", "src/objects/map-updater.cc", "src/objects/map-updater.h", "src/objects/maybe-object.h", @@ -2232,6 +2265,8 @@ filegroup( "src/objects/object-macros-undef.h", "src/objects/object-type.cc", "src/objects/object-type.h", + "src/objects/object-predicates.h", + "src/objects/object-predicates-inl.h", "src/objects/objects.cc", "src/objects/objects.h", "src/objects/objects-body-descriptors.h", @@ -2290,6 +2325,7 @@ filegroup( "src/objects/slots-inl.h", "src/objects/smi.h", "src/objects/smi-inl.h", + "src/objects/sort-state.h", "src/objects/source-text-module.cc", "src/objects/source-text-module.h", "src/objects/source-text-module-inl.h", @@ -2394,7 +2430,7 @@ filegroup( "src/profiler/heap-snapshot-common.h", "src/profiler/heap-snapshot-generator.cc", "src/profiler/heap-snapshot-generator.h", - "src/profiler/heap-snapshot-generator-inl.h", + "src/profiler/output-stream-writer.cc", "src/profiler/output-stream-writer.h", "src/profiler/profile-generator.cc", "src/profiler/profile-generator.h", @@ -2541,8 +2577,6 @@ filegroup( "src/sandbox/trusted-pointer-table.cc", "src/sandbox/trusted-pointer-table.h", "src/sandbox/trusted-pointer-table-inl.h", - "src/sandbox/code-pointer.h", - "src/sandbox/code-pointer-inl.h", "src/sandbox/code-sandboxing-mode.h", "src/sandbox/compactible-external-entity-table-inl.h", "src/sandbox/compactible-external-entity-table.h", @@ -2568,6 +2602,8 @@ filegroup( "src/sandbox/tagged-payload.h", "src/sandbox/testing.cc", "src/sandbox/testing.h", + "src/sandbox/trap-fuzzer.cc", + "src/sandbox/trap-fuzzer.h", "src/snapshot/builtins-effects-dummy.cc", "src/snapshot/code-serializer.cc", "src/snapshot/code-serializer.h", @@ -2682,6 +2718,7 @@ filegroup( "src/utils/utils-inl.h", "src/utils/version.cc", "src/utils/version.h", + "src/wasm/effect-handler.h", "src/zone/accounting-allocator.cc", "src/zone/accounting-allocator.h", "src/zone/type-stats.cc", @@ -2701,6 +2738,7 @@ filegroup( "src/zone/zone-utils.h", "third_party/rapidhash-v8/rapidhash.h", "third_party/rapidhash-v8/secret.h", + "third_party/v8/builtins/array-sort.h", "third_party/siphash/halfsiphash.cc", "third_party/siphash/halfsiphash.h", "third_party/utf8-decoder/utf8-decoder.h", @@ -2871,6 +2909,7 @@ filegroup( "src/codegen/riscv/constant-riscv-f.h", "src/codegen/riscv/constant-riscv-m.h", "src/codegen/riscv/constant-riscv-v.h", + "src/codegen/riscv/constant-riscv-zfa.h", "src/codegen/riscv/constant-riscv-zicsr.h", "src/codegen/riscv/constant-riscv-zifencei.h", "src/codegen/riscv/constants-riscv.h", @@ -2882,6 +2921,8 @@ filegroup( "src/codegen/riscv/extension-riscv-inl.h", "src/codegen/riscv/extension-riscv-m.h", "src/codegen/riscv/extension-riscv-v.h", + "src/codegen/riscv/extension-riscv-zfa.cc", + "src/codegen/riscv/extension-riscv-zfa.h", "src/codegen/riscv/extension-riscv-zicsr.h", "src/codegen/riscv/extension-riscv-zifencei.h", "src/codegen/riscv/extension-riscv-zimop.cc", @@ -2980,6 +3021,7 @@ filegroup( "src/maglev/maglev-ir-inl.h", "src/maglev/maglev-ir.h", "src/maglev/maglev-kna-processor.h", + "src/maglev/maglev-map-inference.h", "src/maglev/maglev-node-type.h", "src/maglev/maglev-phi-representation-selector.h", "src/maglev/maglev-truncation.h", @@ -3014,6 +3056,7 @@ filegroup( "src/maglev/maglev-ir.cc", "src/maglev/maglev-node-type.cc", "src/maglev/maglev-phi-representation-selector.cc", + "src/maglev/maglev-tracer.h", "src/maglev/maglev-truncation.cc", "src/maglev/maglev-pipeline-statistics.cc", "src/maglev/maglev-range-verification.cc", @@ -3120,7 +3163,6 @@ filegroup( "src/wasm/module-instantiate.h", "src/wasm/names-provider.cc", "src/wasm/names-provider.h", - "src/wasm/object-access.h", "src/wasm/pgo.cc", "src/wasm/pgo.h", "src/wasm/signature-hashing.h", @@ -3156,6 +3198,7 @@ filegroup( "src/wasm/wasm-disassembler.h", "src/wasm/wasm-disassembler-impl.h", "src/wasm/wasm-engine.cc", + "src/wasm/wasm-engine-globals.h", "src/wasm/wasm-engine.h", "src/wasm/wasm-export-wrapper-cache.cc", "src/wasm/wasm-export-wrapper-cache.h", @@ -3197,9 +3240,7 @@ filegroup( "src/wasm/wasm-value.h", "src/wasm/well-known-imports.cc", "src/wasm/well-known-imports.h", - "src/wasm/wrappers.cc", - "src/wasm/wrappers.h", - "src/wasm/wrappers-inl.h", + "src/wasm/wasm-wrapper-cache-inl.h", "third_party/utf8-decoder/generalized-utf8-decoder.h", ], @@ -3460,8 +3501,6 @@ filegroup( "src/compiler/operator-properties.h", "src/compiler/osr.cc", "src/compiler/osr.h", - "src/compiler/pair-load-store-reducer.cc", - "src/compiler/pair-load-store-reducer.h", "src/compiler/per-isolate-compiler-cache.h", "src/compiler/persistent-map.h", "src/compiler/phase.h", @@ -3497,8 +3536,6 @@ filegroup( "src/compiler/simplified-operator-reducer.h", "src/compiler/state-values-utils.cc", "src/compiler/state-values-utils.h", - "src/compiler/string-builder-optimizer.cc", - "src/compiler/string-builder-optimizer.h", "src/compiler/turbofan.h", "src/compiler/turbofan-enabled.cc", "src/compiler/turbofan-graph.cc", @@ -3601,8 +3638,8 @@ filegroup( "src/compiler/turboshaft/operations.cc", "src/compiler/turboshaft/operations.h", "src/compiler/turboshaft/opmasks.h", - "src/compiler/turboshaft/optimize-phase.cc", - "src/compiler/turboshaft/optimize-phase.h", + "src/compiler/turboshaft/memory-optimization-phase.cc", + "src/compiler/turboshaft/memory-optimization-phase.h", "src/compiler/turboshaft/phase.cc", "src/compiler/turboshaft/phase.h", "src/compiler/turboshaft/pipelines.cc", @@ -3624,8 +3661,8 @@ filegroup( "src/compiler/turboshaft/snapshot-table.h", "src/compiler/turboshaft/snapshot-table-opindex.h", "src/compiler/turboshaft/stack-check-lowering-reducer.h", - "src/compiler/turboshaft/store-store-elimination-phase.cc", - "src/compiler/turboshaft/store-store-elimination-phase.h", + "src/compiler/turboshaft/load-elimination-phase.cc", + "src/compiler/turboshaft/load-elimination-phase.h", "src/compiler/turboshaft/store-store-elimination-reducer-inl.h", "src/compiler/turboshaft/string-escape-analysis-reducer.cc", "src/compiler/turboshaft/string-escape-analysis-reducer.h", @@ -3749,6 +3786,9 @@ filegroup( "src/compiler/turboshaft/wasm-optimize-phase.h", "src/compiler/turboshaft/wasm-turboshaft-compiler.cc", "src/compiler/turboshaft/wasm-turboshaft-compiler.h", + "src/compiler/turboshaft/wasm-wrappers-inl.h", + "src/compiler/turboshaft/wasm-wrappers.cc", + "src/compiler/turboshaft/wasm-wrappers.h", "src/compiler/turboshaft/wasm-shuffle-reducer.cc", "src/compiler/turboshaft/wasm-shuffle-reducer.h", "src/compiler/turboshaft/wasm-simd-phase.cc", @@ -3824,6 +3864,7 @@ filegroup( "src/maglev/maglev-register-frame-array.h", "src/maglev/maglev-phi-representation-selector.cc", "src/maglev/maglev-phi-representation-selector.h", + "src/maglev/maglev-tracer.h", "src/maglev/maglev-truncation.cc", "src/maglev/maglev-truncation.h", "src/maglev/maglev-post-hoc-optimizations-processors.h", @@ -4112,24 +4153,20 @@ filegroup( name = "v8_bigint", srcs = [ "src/bigint/bigint.h", + "src/bigint/bigint-inl.h", "src/bigint/bigint-internal.cc", "src/bigint/bigint-internal.h", - "src/bigint/bitwise.cc", - "src/bigint/digit-arithmetic.h", "src/bigint/div-barrett.cc", "src/bigint/div-burnikel.cc", - "src/bigint/div-helpers.cc", - "src/bigint/div-helpers.h", + "src/bigint/div-helpers-inl.h", "src/bigint/div-schoolbook.cc", "src/bigint/fromstring.cc", "src/bigint/mul-fft.cc", "src/bigint/mul-karatsuba.cc", - "src/bigint/mul-schoolbook.cc", "src/bigint/mul-toom.cc", "src/bigint/tostring.cc", "src/bigint/util.h", - "src/bigint/vector-arithmetic.cc", - "src/bigint/vector-arithmetic.h", + "src/bigint/vector-arithmetic-inl.h", ], ) @@ -4364,18 +4401,10 @@ v8_torque_files( # "class-debug-readers.cc", # "class-debug-readers.h", "class-forward-declarations.h", - "class-verifiers.cc", - "class-verifiers.h", # "debug-macros.cc", # "debug-macros.h", - "factory.cc", - "factory.inc", "instance-types.h", "interface-descriptors.inc", - "objects-body-descriptors-inl.inc", - "objects-printer.cc", - "visitor-lists.h", - ], icu_srcs = [":icu/torque_files"], noicu_srcs = [":noicu/torque_files"], diff --git a/deps/v8/BUILD.gn b/deps/v8/BUILD.gn index e81430fbc39392..dd22a8954e19e8 100644 --- a/deps/v8/BUILD.gn +++ b/deps/v8/BUILD.gn @@ -2,8 +2,11 @@ # Use of this source code is governed by a BSD-style license that can be # found in the LICENSE file. +# LINT.IfChange + import("//build/config/android/config.gni") import("//build/config/arm.gni") +import("//build/config/c++/c++.gni") import("//build/config/coverage/coverage.gni") import("//build/config/dcheck_always_on.gni") import("//build/config/host_byteorder.gni") @@ -13,6 +16,7 @@ import("//build/config/sanitizers/sanitizers.gni") import("//build_overrides/build.gni") import("//third_party/icu/config.gni") +import("gni/cluster_build.gni") import("gni/snapshot_toolchain.gni") import("gni/v8.gni") @@ -56,6 +60,10 @@ declare_args() { # Sets -DVERIFY_PREDICTABLE v8_enable_verify_predictable = false + # Enable DWARF line info for Torque files. + # TODO(olivf): Find out how this works on other platforms. + v8_enable_torque_dwarf = is_debug && is_linux + # Enable compiler warnings when using V8_DEPRECATED apis. v8_deprecation_warnings = true @@ -72,7 +80,7 @@ declare_args() { v8_enable_disassembler = "" # Sets -DV8_ENABLE_REGEXP_DIAGNOSTICS. - v8_enable_regexp_diagnostics = !build_with_chromium + v8_enable_regexp_diagnostics = "" # Sets the number of internal fields on promise objects. v8_promise_internal_field_count = 0 @@ -195,15 +203,6 @@ declare_args() { # default setting code below. v8_enable_concurrent_marking = true - # Sets -DV8_IGNITION_DISPATCH_COUNTING. - # Enables counting frequencies of bytecode dispatches. After building in this - # configuration, subsequent runs of d8 can output frequencies for each pair - # of (current, next) bytecode instructions executed if you specify - # --trace-ignition-dispatches-output-file, or can generate a JS object with - # those frequencies if you run with --expose-ignition-statistics and call the - # extension function getIgnitionDispatchCounters(). - v8_enable_ignition_dispatch_counting = false - # Enable frame elision for builtins. v8_enable_builtins_frame_elision = true @@ -223,6 +222,11 @@ declare_args() { # the `--trace-turbo` .json file from `mksnapshot`. v8_log_builtins_block_count_input = "" + # This build flag is used to enable block positioning in profile-guided + # optimization of builtins based on raw execution counts (as opposed to + # branch hints). + v8_enable_builtins_block_position = false + # This build flag is used to control whether reorder builtins according to # the call graph with C3 algorithm based builtin PGO profiling. v8_enable_builtins_reordering = true @@ -507,9 +511,25 @@ declare_args() { # Enable compilation of riscv32. v8_riscv_enable_deprecated_riscv32 = false + + # Sets the level of logging detail in V8_Fatal. + # 0: No file and line and message only if args are provided (for official + # release builds). + # 1: Message but no file or line. + # 2: Everything (file, line, message). + v8_logging_level = "" } # Derived defaults. +if (v8_logging_level == "") { + if (v8_enable_verification_features || v8_dcheck_always_on) { + v8_logging_level = 2 + } else if (is_official_build) { + v8_logging_level = 0 + } else { + v8_logging_level = 1 + } +} if (cppgc_enable_verify_heap == "") { cppgc_enable_verify_heap = v8_enable_verification_features || v8_dcheck_always_on @@ -534,6 +554,9 @@ if (v8_enable_disassembler == "") { if (v8_enable_trace_maps == "") { v8_enable_trace_maps = v8_enable_debugging_features } +if (v8_enable_regexp_diagnostics == "") { + v8_enable_regexp_diagnostics = v8_enable_debugging_features +} if (v8_enable_test_features == "") { v8_enable_test_features = v8_enable_verification_features || v8_dcheck_always_on @@ -786,9 +809,16 @@ assert(!v8_enable_pointer_compression_8gb || v8_enable_pointer_compression, assert(!v8_enable_sandbox || v8_enable_external_code_space, "The sandbox requires the external code space") +assert(!v8_enable_sandbox || use_safe_libcxx, + "The sandbox requires libc++ hardening") + assert(!v8_enable_memory_corruption_api || v8_enable_sandbox, "The Memory Corruption API requires the sandbox") +assert( + !v8_enable_memory_corruption_api || !is_lsan, + "The Memory Corruption API cannot be enabled together with LSan as both attach to the d8 process via ptrace") + assert(!v8_enable_sandbox_hardware_support || v8_enable_sandbox, "The sandbox must be enabled to enable sandbox hardware support") @@ -1017,6 +1047,8 @@ external_v8_defines = [ "V8_TARGET_OS_CHROMEOS", "V8_TARGET_ARCH_ARM64", "V8_TARGET_ARCH_PPC64", + "V8_TARGET_ARCH_MIPS64", + "V8_TARGET_ARCH_LOONG64", ] enabled_external_v8_defines = [ @@ -1109,6 +1141,10 @@ if (v8_current_cpu == "arm64") { enabled_external_v8_defines += [ "V8_TARGET_ARCH_ARM64" ] } else if (v8_current_cpu == "ppc64") { enabled_external_v8_defines += [ "V8_TARGET_ARCH_PPC64" ] +} else if (v8_current_cpu == "mips64el") { + enabled_external_v8_defines += [ "V8_TARGET_ARCH_MIPS64" ] +} else if (v8_current_cpu == "loong64") { + enabled_external_v8_defines += [ "V8_TARGET_ARCH_LOONG64" ] } disabled_external_v8_defines = external_v8_defines - enabled_external_v8_defines @@ -1198,8 +1234,10 @@ config("features") { # Only targets in this file and its subdirs can depend on this. visibility = [ "./*" ] - defines = - [ "V8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=${v8_typed_array_max_size_in_heap}" ] + defines = [ + "V8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=${v8_typed_array_max_size_in_heap}", + "V8_LOGGING_LEVEL=${v8_logging_level}", + ] configs = [ ":v8_header_features", @@ -1238,12 +1276,18 @@ config("features") { if (v8_log_builtins_block_count_input != "") { defines += [ "LOG_BUILTIN_BLOCK_COUNT" ] } + if (v8_enable_builtins_block_position) { + defines += [ "BUILTIN_BLOCK_POSITION" ] + } if (v8_enable_future) { defines += [ "V8_ENABLE_FUTURE" ] } if (v8_enable_lite_mode) { defines += [ "V8_LITE_MODE" ] } + if (v8_use_host_cpu_arm_features) { + defines += [ "V8_USE_HOST_CPU_ARM_FEATURES" ] + } if (v8_enable_seeded_array_index_hash) { defines += [ "V8_ENABLE_SEEDED_ARRAY_INDEX_HASH" ] } @@ -1340,9 +1384,6 @@ config("features") { if (v8_enable_atomic_object_field_writes) { defines += [ "V8_ATOMIC_OBJECT_FIELD_WRITES" ] } - if (v8_enable_ignition_dispatch_counting) { - defines += [ "V8_IGNITION_DISPATCH_COUNTING" ] - } if (v8_enable_lazy_source_positions) { defines += [ "V8_ENABLE_LAZY_SOURCE_POSITIONS" ] } @@ -1379,6 +1420,9 @@ config("features") { if (v8_fuzzilli) { defines += [ "V8_FUZZILLI" ] } + if (use_chromium_fuzzilli) { + defines += [ "USE_CHROMIUM_FUZZILLI" ] + } if (v8_dumpling) { defines += [ "V8_DUMPLING" ] } @@ -1665,6 +1709,9 @@ config("toolchain") { if (riscv_use_zbs) { defines += [ "__riscv_zbs" ] } + if (riscv_profile == "rva23u64") { + defines += [ "__riscv_zfa" ] + } defines += [ "RISCV_CODE_ALIGNMENT=${riscv_code_alignment}" ] defines += [ "RISCV_CONSTANT_POOL_ALIGNMENT=${riscv_constant_pool_alignment}" ] @@ -1749,6 +1796,9 @@ config("toolchain") { if (is_clang) { cflags += [ "-Wunreachable-code" ] + if (v8_current_cpu != "ppc64" && v8_current_cpu != "s390x") { + cflags += [ "-Wlifetime-safety-permissive" ] + } if ((v8_current_cpu != "x64" && v8_current_cpu != "ia32") || target_os == "chromeos") { @@ -1848,10 +1898,10 @@ config("strict_warnings") { v8_current_cpu == "mips64el" || v8_current_cpu == "riscv64") { cflags += [ "-Wshorten-64-to-32" ] } - cflags += [ - "-Wmissing-field-initializers", - "-Wunnecessary-virtual-specifier", - ] + cflags += [ "-Wmissing-field-initializers" ] + if (v8_current_cpu != "ppc64" && v8_current_cpu != "s390x") { + cflags += [ "-Wunnecessary-virtual-specifier" ] + } } } @@ -1869,32 +1919,6 @@ config("always_turbofanimize") { } } -# Sanitizer defines. V8 will inherit a default `-fsanitize=array-bounds` -# from Chromium's `//build/config/`, which prevents clean usage of -# `__has_feature(undefined_behavior_sanitizer)` in the short term, -# until something like `--lie-about-ubsan-enablement=array-bounds` -# can be implemented. -# -# This config provides a clear signal of "are we sanitizing" tied to -# GN configuration. -# -# See also: https://crbug.com/386992829 -config("sanitizer_defines") { - defines = [] - if (is_asan) { - defines += [ "V8_USE_ADDRESS_SANITIZER" ] - } - if (is_hwasan) { - defines += [ "V8_USE_HWADDRESS_SANITIZER" ] - } - if (is_msan) { - defines += [ "V8_USE_MEMORY_SANITIZER" ] - } - if (is_ubsan) { - defines += [ "V8_USE_UNDEFINED_BEHAVIOR_SANITIZER" ] - } -} - ############################################################################### # Actions # @@ -1953,7 +1977,6 @@ if (v8_postmortem_support) { "src/objects/code.h", "src/objects/code-inl.h", "src/objects/cpp-heap-external-object.h", - "src/objects/cpp-heap-external-object-inl.h", "src/objects/cpp-heap-object-wrapper.h", "src/objects/cpp-heap-object-wrapper-inl.h", "src/objects/data-handler.h", @@ -2085,6 +2108,7 @@ torque_files = [ "src/builtins/frames.tq", "src/builtins/frame-arguments.tq", "src/builtins/function.tq", + "src/builtins/generator.tq", "src/builtins/growable-fixed-array.tq", "src/builtins/ic-callable.tq", "src/builtins/ic.tq", @@ -2288,7 +2312,6 @@ if (v8_enable_temporal_support) { if (v8_enable_webassembly) { torque_files += [ - "src/builtins/js-to-js.tq", "src/builtins/js-to-wasm.tq", "src/builtins/wasm.tq", "src/builtins/wasm-strings.tq", @@ -2296,6 +2319,9 @@ if (v8_enable_webassembly) { "src/debug/debug-wasm-objects.tq", "src/wasm/wasm-objects.tq", ] + if (v8_enable_drumbrake) { + torque_files += [ "src/builtins/wasm-interpreter-wrappers.tq" ] + } } if (v8_enable_experimental_tq_to_tsa) { @@ -2408,21 +2434,14 @@ template("run_torque") { "$destination_folder/class-debug-readers.cc", "$destination_folder/class-debug-readers.h", "$destination_folder/class-forward-declarations.h", - "$destination_folder/class-verifiers.cc", - "$destination_folder/class-verifiers.h", "$destination_folder/csa-types.h", "$destination_folder/debug-macros.cc", "$destination_folder/debug-macros.h", "$destination_folder/enum-verifiers.cc", "$destination_folder/exported-macros-assembler.cc", "$destination_folder/exported-macros-assembler.h", - "$destination_folder/factory.cc", - "$destination_folder/factory.inc", "$destination_folder/instance-types.h", "$destination_folder/interface-descriptors.inc", - "$destination_folder/objects-body-descriptors-inl.inc", - "$destination_folder/objects-printer.cc", - "$destination_folder/visitor-lists.h", ] foreach(file, torque_files) { @@ -2448,6 +2467,9 @@ template("run_torque") { if (v8_annotate_torque_ir) { args += [ "-annotate-ir" ] } + if (v8_enable_torque_dwarf) { + args += [ "-torque-dwarf" ] + } if (defined(invoker.args)) { args += invoker.args } @@ -2521,9 +2543,28 @@ v8_header_set("torque_runtime_support") { configs = [ ":internal_config" ] } -v8_source_set("torque_generated_initializers") { +# Build lists of torque-generated .cc and .h files for clustering +torque_csa_cc_files = [] +torque_csa_h_files = [] +torque_tsa_cc_files = [] +torque_tsa_h_files = [] +foreach(file, torque_files) { + filetq = string_replace(file, ".tq", "-tq") + torque_csa_cc_files += [ "$target_gen_dir/torque-generated/$filetq-csa.cc" ] + torque_csa_h_files += [ "$target_gen_dir/torque-generated/$filetq-csa.h" ] + if (v8_enable_experimental_tq_to_tsa) { + torque_tsa_cc_files += [ "$target_gen_dir/torque-generated/$filetq-tsa.cc" ] + torque_tsa_h_files += [ "$target_gen_dir/torque-generated/$filetq-tsa.h" ] + } +} + +v8_cluster_source_set("torque_generated_initializers") { visibility = [ ":*" ] # Only targets in this file can depend on this. + cluster_prefix = "torque-csa" + cluster_output_dir = "$target_gen_dir/torque-generated" + generated_sources = true + deps = [ ":generate_bytecode_builtins_list", ":run_torque", @@ -2541,24 +2582,21 @@ v8_source_set("torque_generated_initializers") { ":v8_maybe_icu", ] - sources = [ - "$target_gen_dir/torque-generated/csa-types.h", - "$target_gen_dir/torque-generated/enum-verifiers.cc", - "$target_gen_dir/torque-generated/exported-macros-assembler.cc", - "$target_gen_dir/torque-generated/exported-macros-assembler.h", - ] - foreach(file, torque_files) { - filetq = string_replace(file, ".tq", "-tq") - sources += [ - "$target_gen_dir/torque-generated/$filetq-csa.cc", - "$target_gen_dir/torque-generated/$filetq-csa.h", - ] - if (v8_enable_experimental_tq_to_tsa) { - sources += [ - "$target_gen_dir/torque-generated/$filetq-tsa.cc", - "$target_gen_dir/torque-generated/$filetq-tsa.h", - ] - } + sources = torque_csa_cc_files + [ + "$target_gen_dir/torque-generated/csa-types.h", + "$target_gen_dir/torque-generated/enum-verifiers.cc", + "$target_gen_dir/torque-generated/exported-macros-assembler.cc", + "$target_gen_dir/torque-generated/exported-macros-assembler.h", + ] + + # Add headers (always included) + sources += torque_csa_h_files + if (v8_enable_experimental_tq_to_tsa) { + sources += torque_tsa_h_files + + # TSA cc files are not clustered yet + sources += torque_tsa_cc_files + exclude_from_cluster = torque_tsa_cc_files } configs = [ ":internal_config" ] @@ -2576,9 +2614,25 @@ v8_source_set("torque_generated_initializers") { } } -v8_source_set("torque_generated_definitions") { +# Build lists of torque-generated definition files for clustering +torque_def_cc_files = [] +torque_def_inc_files = [] +foreach(file, torque_files) { + filetq = string_replace(file, ".tq", "-tq") + torque_def_cc_files += [ "$target_gen_dir/torque-generated/$filetq.cc" ] + torque_def_inc_files += [ + "$target_gen_dir/torque-generated/$filetq-inl.inc", + "$target_gen_dir/torque-generated/$filetq.inc", + ] +} + +v8_cluster_source_set("torque_generated_definitions") { visibility = [ ":*" ] # Only targets in this file can depend on this. + cluster_prefix = "torque-def" + cluster_output_dir = "$target_gen_dir/torque-generated" + generated_sources = true + deps = [ ":generate_bytecode_builtins_list", ":run_torque", @@ -2596,21 +2650,11 @@ v8_source_set("torque_generated_definitions") { ":v8_maybe_icu", ] - sources = [ - "$target_gen_dir/torque-generated/class-forward-declarations.h", - "$target_gen_dir/torque-generated/class-verifiers.cc", - "$target_gen_dir/torque-generated/class-verifiers.h", - "$target_gen_dir/torque-generated/factory.cc", - "$target_gen_dir/torque-generated/objects-printer.cc", - ] - foreach(file, torque_files) { - filetq = string_replace(file, ".tq", "-tq") - sources += [ - "$target_gen_dir/torque-generated/$filetq-inl.inc", - "$target_gen_dir/torque-generated/$filetq.cc", - "$target_gen_dir/torque-generated/$filetq.inc", - ] - } + sources = torque_def_cc_files + + [ "$target_gen_dir/torque-generated/class-forward-declarations.h" ] + + # Add .inc files (always included, not compiled directly) + sources += torque_def_inc_files configs = [ ":internal_config" ] } @@ -2835,6 +2879,10 @@ template("run_mksnapshot") { args += [ "--code-comments" ] } + if (v8_enable_torque_dwarf) { + args += [ "--torque-dwarf" ] + } + if (v8_enable_snapshot_native_code_counters) { args += [ "--native-code-counters" ] } else { @@ -3003,6 +3051,10 @@ action("v8_dump_build_config") { simulator_run = target_cpu != v8_target_cpu use_sanitizer = is_asan || is_cfi || is_msan || is_tsan || is_ubsan + # Close the ITTT block, because stacked blocks are not allowed. + # LINT.ThenChange(BUILD.bazel) + # LINT.IfChange + # This lists all build-time switches consumed by the test framework. All # switches can be used automatically in the status files as is - no # further files need to be modified. @@ -3035,6 +3087,7 @@ action("v8_dump_build_config") { "dict_property_const_tracking=$v8_dict_property_const_tracking", "direct_handle=$v8_enable_direct_handle", "disassembler=$v8_enable_disassembler", + "dumpling=$v8_dumpling", "full_debug=$is_full_debug", "gdbjit=$v8_enable_gdbjit", "has_jitless=$v8_jitless", @@ -3080,6 +3133,9 @@ action("v8_dump_build_config") { # Please add new switches also in `build_config_content` in `bazel/defs.bzl` # so that the switches also work for tests triggered by bazel. ] + + # LINT.ThenChange(bazel/defs.bzl) + # LINT.IfChange } # Generate a json file containing essential V8 build flags. @@ -3163,6 +3219,10 @@ v8_source_set("v8_snapshot") { configs = [ ":internal_config" ] + if (is_debug) { + asmflags = [ "-g" ] + } + if (v8_use_external_startup_data) { deps += [ ":v8_base" ] @@ -3177,7 +3237,7 @@ v8_source_set("v8_snapshot") { } } -v8_source_set("v8_initializers") { +v8_cluster_source_set("v8_initializers") { visibility = [ ":*", "test/cctest:*", @@ -3624,6 +3684,7 @@ v8_header_set("v8_internal_headers") { "src/builtins/constants-table-builder.h", "src/builtins/data-view-ops.h", "src/builtins/profile-data-reader.h", + "src/builtins/superspread.h", "src/codegen/aligned-slot-allocator.h", "src/codegen/assembler-arch.h", "src/codegen/assembler-inl.h", @@ -3789,7 +3850,6 @@ v8_header_set("v8_internal_headers") { "src/compiler/operator-properties.h", "src/compiler/operator.h", "src/compiler/osr.h", - "src/compiler/pair-load-store-reducer.h", "src/compiler/per-isolate-compiler-cache.h", "src/compiler/persistent-map.h", "src/compiler/phase.h", @@ -3810,7 +3870,6 @@ v8_header_set("v8_internal_headers") { "src/compiler/simplified-operator-reducer.h", "src/compiler/simplified-operator.h", "src/compiler/state-values-utils.h", - "src/compiler/string-builder-optimizer.h", "src/compiler/turbofan-graph-visualizer.h", "src/compiler/turbofan-graph.h", "src/compiler/turbofan-typer.h", @@ -3858,6 +3917,7 @@ v8_header_set("v8_internal_headers") { "src/compiler/turboshaft/late-escape-analysis-reducer.h", "src/compiler/turboshaft/late-load-elimination-reducer.h", "src/compiler/turboshaft/layered-hash-map.h", + "src/compiler/turboshaft/load-elimination-phase.h", "src/compiler/turboshaft/load-store-simplification-reducer.h", "src/compiler/turboshaft/load-store-verification-reducer.h", "src/compiler/turboshaft/loop-finder.h", @@ -3869,11 +3929,11 @@ v8_header_set("v8_internal_headers") { "src/compiler/turboshaft/machine-lowering-reducer-inl.h", "src/compiler/turboshaft/machine-optimization-reducer.h", "src/compiler/turboshaft/maglev-assert-types-reducer.h", + "src/compiler/turboshaft/memory-optimization-phase.h", "src/compiler/turboshaft/memory-optimization-reducer.h", "src/compiler/turboshaft/operation-matcher.h", "src/compiler/turboshaft/operations.h", "src/compiler/turboshaft/opmasks.h", - "src/compiler/turboshaft/optimize-phase.h", "src/compiler/turboshaft/phase.h", "src/compiler/turboshaft/pipelines.h", "src/compiler/turboshaft/pretenuring-propagation-reducer.h", @@ -3889,7 +3949,6 @@ v8_header_set("v8_internal_headers") { "src/compiler/turboshaft/snapshot-table-opindex.h", "src/compiler/turboshaft/snapshot-table.h", "src/compiler/turboshaft/stack-check-lowering-reducer.h", - "src/compiler/turboshaft/store-store-elimination-phase.h", "src/compiler/turboshaft/store-store-elimination-reducer-inl.h", "src/compiler/turboshaft/string-escape-analysis-reducer.h", "src/compiler/turboshaft/string-view.h", @@ -3992,7 +4051,6 @@ v8_header_set("v8_internal_headers") { "src/extensions/cputracemark-extension.h", "src/extensions/externalize-string-extension.h", "src/extensions/gc-extension.h", - "src/extensions/ignition-statistics-extension.h", "src/extensions/statistics-extension.h", "src/extensions/trigger-failure-extension.h", "src/flags/save-flags.h", @@ -4224,7 +4282,6 @@ v8_header_set("v8_internal_headers") { "src/objects/compressed-slots.h", "src/objects/contexts-inl.h", "src/objects/contexts.h", - "src/objects/cpp-heap-external-object-inl.h", "src/objects/cpp-heap-external-object.h", "src/objects/cpp-heap-object-wrapper-inl.h", "src/objects/cpp-heap-object-wrapper.h", @@ -4279,6 +4336,8 @@ v8_header_set("v8_internal_headers") { "src/objects/js-collection-iterator-inl.h", "src/objects/js-collection-iterator.h", "src/objects/js-collection.h", + "src/objects/js-data-object-builder-inl.h", + "src/objects/js-data-object-builder.h", "src/objects/js-disposable-stack-inl.h", "src/objects/js-disposable-stack.h", "src/objects/js-function-inl.h", @@ -4321,6 +4380,8 @@ v8_header_set("v8_internal_headers") { "src/objects/managed.h", "src/objects/map-inl.h", "src/objects/map-updater.h", + "src/objects/map-word-inl.h", + "src/objects/map-word.h", "src/objects/map.h", "src/objects/maybe-object-inl.h", "src/objects/maybe-object.h", @@ -4335,6 +4396,8 @@ v8_header_set("v8_internal_headers") { "src/objects/object-list-macros.h", "src/objects/object-macros-undef.h", "src/objects/object-macros.h", + "src/objects/object-predicates-inl.h", + "src/objects/object-predicates.h", "src/objects/object-type.h", "src/objects/objects-body-descriptors-inl.h", "src/objects/objects-body-descriptors.h", @@ -4378,6 +4441,7 @@ v8_header_set("v8_internal_headers") { "src/objects/slots.h", "src/objects/smi-inl.h", "src/objects/smi.h", + "src/objects/sort-state.h", "src/objects/source-text-module-inl.h", "src/objects/source-text-module.h", "src/objects/string-comparator.h", @@ -4452,7 +4516,6 @@ v8_header_set("v8_internal_headers") { "src/profiler/cpu-profiler.h", "src/profiler/heap-profiler.h", "src/profiler/heap-snapshot-common.h", - "src/profiler/heap-snapshot-generator-inl.h", "src/profiler/heap-snapshot-generator.h", "src/profiler/output-stream-writer.h", "src/profiler/profile-generator-inl.h", @@ -4506,10 +4569,8 @@ v8_header_set("v8_internal_headers") { "src/sandbox/bytecode-verifier.h", "src/sandbox/check.h", "src/sandbox/code-entrypoint-tag.h", - "src/sandbox/code-pointer-inl.h", "src/sandbox/code-pointer-table-inl.h", "src/sandbox/code-pointer-table.h", - "src/sandbox/code-pointer.h", "src/sandbox/code-sandboxing-mode.h", "src/sandbox/compactible-external-entity-table-inl.h", "src/sandbox/compactible-external-entity-table.h", @@ -4697,6 +4758,7 @@ v8_header_set("v8_internal_headers") { "src/maglev/maglev-ir.h", "src/maglev/maglev-kna-processor.h", "src/maglev/maglev-known-node-aspects.h", + "src/maglev/maglev-map-inference.h", "src/maglev/maglev-node-type.h", "src/maglev/maglev-phi-representation-selector.h", "src/maglev/maglev-pipeline-statistics.h", @@ -4710,6 +4772,7 @@ v8_header_set("v8_internal_headers") { "src/maglev/maglev-regalloc-data.h", "src/maglev/maglev-regalloc.h", "src/maglev/maglev-register-frame-array.h", + "src/maglev/maglev-tracer.h", "src/maglev/maglev-truncation.h", "src/maglev/maglev.h", ] @@ -4755,6 +4818,8 @@ v8_header_set("v8_internal_headers") { "src/compiler/turboshaft/wasm-shuffle-reducer.h", "src/compiler/turboshaft/wasm-simd-phase.h", "src/compiler/turboshaft/wasm-turboshaft-compiler.h", + "src/compiler/turboshaft/wasm-wrappers-inl.h", + "src/compiler/turboshaft/wasm-wrappers.h", "src/compiler/wasm-address-reassociation.h", "src/compiler/wasm-call-descriptors.h", "src/compiler/wasm-compiler-definitions.h", @@ -4787,6 +4852,7 @@ v8_header_set("v8_internal_headers") { "src/wasm/constant-expression-interface.h", "src/wasm/constant-expression.h", "src/wasm/decoder.h", + "src/wasm/effect-handler.h", "src/wasm/function-body-decoder-impl.h", "src/wasm/function-body-decoder.h", "src/wasm/function-compiler.h", @@ -4800,7 +4866,6 @@ v8_header_set("v8_internal_headers") { "src/wasm/module-decoder.h", "src/wasm/module-instantiate.h", "src/wasm/names-provider.h", - "src/wasm/object-access.h", "src/wasm/pgo.h", "src/wasm/signature-hashing.h", "src/wasm/simd-shuffle.h", @@ -4823,6 +4888,7 @@ v8_header_set("v8_internal_headers") { "src/wasm/wasm-deopt-data.h", "src/wasm/wasm-disassembler-impl.h", "src/wasm/wasm-disassembler.h", + "src/wasm/wasm-engine-globals.h", "src/wasm/wasm-engine.h", "src/wasm/wasm-export-wrapper-cache.h", "src/wasm/wasm-external-refs.h", @@ -4849,8 +4915,6 @@ v8_header_set("v8_internal_headers") { "src/wasm/wasm-wrapper-cache-inl.h", "src/wasm/wasm-wrapper-cache.h", "src/wasm/well-known-imports.h", - "src/wasm/wrappers-inl.h", - "src/wasm/wrappers.h", "third_party/utf8-decoder/generalized-utf8-decoder.h", ] @@ -4876,6 +4940,10 @@ v8_header_set("v8_internal_headers") { ] } + if (v8_enable_builtins_block_position) { + sources += [ "src/compiler/backend/block-position.h" ] + } + if (v8_enable_i18n_support) { sources += [ "src/objects/intl-objects.h", @@ -5187,6 +5255,7 @@ v8_header_set("v8_internal_headers") { "src/codegen/riscv/constant-riscv-f.h", "src/codegen/riscv/constant-riscv-m.h", "src/codegen/riscv/constant-riscv-v.h", + "src/codegen/riscv/constant-riscv-zfa.h", "src/codegen/riscv/constant-riscv-zicond.h", "src/codegen/riscv/constant-riscv-zicsr.h", "src/codegen/riscv/constant-riscv-zifencei.h", @@ -5199,6 +5268,7 @@ v8_header_set("v8_internal_headers") { "src/codegen/riscv/extension-riscv-inl.h", "src/codegen/riscv/extension-riscv-m.h", "src/codegen/riscv/extension-riscv-v.h", + "src/codegen/riscv/extension-riscv-zfa.h", "src/codegen/riscv/extension-riscv-zicond.h", "src/codegen/riscv/extension-riscv-zicsr.h", "src/codegen/riscv/extension-riscv-zifencei.h", @@ -5251,6 +5321,8 @@ v8_header_set("v8_internal_headers") { "src/codegen/riscv/constant-riscv-i.h", "src/codegen/riscv/constant-riscv-m.h", "src/codegen/riscv/constant-riscv-v.h", + "src/codegen/riscv/constant-riscv-zfa.h", + "src/codegen/riscv/constant-riscv-zicond.h", "src/codegen/riscv/constant-riscv-zicsr.h", "src/codegen/riscv/constant-riscv-zifencei.h", "src/codegen/riscv/constants-riscv.h", @@ -5262,6 +5334,7 @@ v8_header_set("v8_internal_headers") { "src/codegen/riscv/extension-riscv-inl.h", "src/codegen/riscv/extension-riscv-m.h", "src/codegen/riscv/extension-riscv-v.h", + "src/codegen/riscv/extension-riscv-zfa.h", "src/codegen/riscv/extension-riscv-zicsr.h", "src/codegen/riscv/extension-riscv-zifencei.h", "src/codegen/riscv/extension-riscv-zimop.h", @@ -5402,7 +5475,6 @@ v8_compiler_sources = [ "src/compiler/operator-properties.cc", "src/compiler/operator.cc", "src/compiler/osr.cc", - "src/compiler/pair-load-store-reducer.cc", "src/compiler/pipeline-statistics.cc", "src/compiler/pipeline.cc", "src/compiler/property-access-builder.cc", @@ -5418,7 +5490,6 @@ v8_compiler_sources = [ "src/compiler/simplified-operator-reducer.cc", "src/compiler/simplified-operator.cc", "src/compiler/state-values-utils.cc", - "src/compiler/string-builder-optimizer.cc", "src/compiler/turbofan-enabled.cc", "src/compiler/turbofan-graph-visualizer.cc", "src/compiler/turbofan-graph.cc", @@ -5446,21 +5517,21 @@ v8_compiler_sources = [ "src/compiler/turboshaft/instruction-selection-phase.cc", "src/compiler/turboshaft/late-escape-analysis-reducer.cc", "src/compiler/turboshaft/late-load-elimination-reducer.cc", + "src/compiler/turboshaft/load-elimination-phase.cc", "src/compiler/turboshaft/loop-finder.cc", "src/compiler/turboshaft/loop-peeling-phase.cc", "src/compiler/turboshaft/loop-unrolling-phase.cc", "src/compiler/turboshaft/loop-unrolling-reducer.cc", "src/compiler/turboshaft/machine-lowering-phase.cc", + "src/compiler/turboshaft/memory-optimization-phase.cc", "src/compiler/turboshaft/memory-optimization-reducer.cc", "src/compiler/turboshaft/operations.cc", - "src/compiler/turboshaft/optimize-phase.cc", "src/compiler/turboshaft/phase.cc", "src/compiler/turboshaft/pipelines.cc", "src/compiler/turboshaft/pretenuring-propagation-reducer.cc", "src/compiler/turboshaft/representations.cc", "src/compiler/turboshaft/sidetable.cc", "src/compiler/turboshaft/simplify-tf-loops.cc", - "src/compiler/turboshaft/store-store-elimination-phase.cc", "src/compiler/turboshaft/string-escape-analysis-reducer.cc", "src/compiler/turboshaft/turbolev-frontend-pipeline.cc", "src/compiler/turboshaft/turbolev-graph-builder.cc", @@ -5591,6 +5662,7 @@ if (v8_enable_webassembly) { "src/compiler/turboshaft/wasm-shuffle-reducer.cc", "src/compiler/turboshaft/wasm-simd-phase.cc", "src/compiler/turboshaft/wasm-turboshaft-compiler.cc", + "src/compiler/turboshaft/wasm-wrappers.cc", "src/compiler/wasm-address-reassociation.cc", "src/compiler/wasm-call-descriptors.cc", "src/compiler/wasm-compiler.cc", @@ -5602,7 +5674,6 @@ if (v8_enable_webassembly) { "src/compiler/wasm-load-elimination.cc", "src/compiler/wasm-typer.cc", "src/wasm/turboshaft-graph-interface.cc", - "src/wasm/wrappers.cc", ] } @@ -5615,16 +5686,31 @@ if (v8_enable_wasm_simd256_revec) { ] } +exclude_from_compiler_cluster = [ + "src/compiler/turboshaft/turbolev-graph-builder.cc", # Slow. + "src/compiler/turboshaft/wasm-turboshaft-compiler.cc", # Pipeline::GenerateWasmCode. + "src/compiler/bytecode-analysis.cc", # Top-level 'using incl. + # 'interpreter::Register'. + "src/compiler/heap-refs.cc", # Is64() function. + "src/compiler/wasm-load-elimination.cc", # MayAlias. +] + +if (v8_enable_builtins_block_position) { + v8_compiler_sources += [ "src/compiler/backend/block-position.cc" ] +} + # The src/compiler files for use in mksnapshot. # - These might be built with additional optimizations if # v8_enable_fast_mksnapshot is set. # - We always include Turbofan even if v8_enable_turbofan is unset s.t. # builtins can be generated by mksnapshot. -v8_source_set("v8_compiler_for_mksnapshot_source_set") { +v8_cluster_source_set("v8_compiler_for_mksnapshot_source_set") { visibility = [ ":*" ] # Only targets in this file can depend on this. sources = v8_compiler_sources + exclude_from_cluster = exclude_from_compiler_cluster + public_deps = [ ":generate_bytecode_builtins_list", ":run_torque", @@ -5657,7 +5743,7 @@ v8_source_set("v8_compiler_for_mksnapshot_source_set") { } # The src/compiler files with default behavior. -v8_source_set("v8_compiler") { +v8_cluster_source_set("v8_compiler") { visibility = [ ":*" ] # Only targets in this file can depend on this. if (v8_enable_turbofan) { @@ -5667,6 +5753,8 @@ v8_source_set("v8_compiler") { sources = [ "src/compiler/turbofan-disabled.cc" ] } + exclude_from_cluster = exclude_from_compiler_cluster + public_deps = [ ":generate_bytecode_builtins_list", ":run_torque", @@ -5715,7 +5803,7 @@ group("v8_tracing") { } } -v8_source_set("v8_base_without_compiler") { +v8_cluster_source_set("v8_base_without_compiler") { # Only targets in this file and gcmole can depend on this. visibility = [ ":*", @@ -5725,6 +5813,24 @@ v8_source_set("v8_base_without_compiler") { # Split static libraries on windows into two. split_count = 2 + # Files excluded from clustering due to template instantiation order issues + # or because they are too large. + exclude_from_cluster = [ + "src/maglev/maglev-graph-builder.cc", + "src/maglev/maglev-ir.cc", + "src/snapshot/deserializer.cc", + "src/wasm/wasm-module.cc", + "src/heap/mark-compact.cc", # ShouldMovePage, also big. + "src/objects/intl-objects.cc", # CheckCalendar. + "src/objects/js-collator.cc", # CreateDataPropertyForOptions, also big. + "src/objects/js-display-names.cc", # CheckCalendar. + "src/objects/js-list-format.cc", + "src/objects/js-number-format.cc", # Style, also big. + "src/objects/js-temporal-objects.cc", # Unit, also big. + "src/runtime/runtime-test-wasm.cc", # WasmStackSize. + "src/sandbox/external-pointer-table.cc", # entry_spacer. + ] + sources = [ ### gcmole(all) ### "src/api/api-arguments.cc", @@ -5864,7 +5970,6 @@ v8_source_set("v8_base_without_compiler") { "src/extensions/cputracemark-extension.cc", "src/extensions/externalize-string-extension.cc", "src/extensions/gc-extension.cc", - "src/extensions/ignition-statistics-extension.cc", "src/extensions/statistics-extension.cc", "src/extensions/trigger-failure-extension.cc", "src/flags/flags.cc", @@ -6005,6 +6110,7 @@ v8_source_set("v8_base_without_compiler") { "src/objects/elements-kind.cc", "src/objects/elements.cc", "src/objects/embedder-data-array.cc", + "src/objects/feedback-transition-table.cc", "src/objects/feedback-vector.cc", "src/objects/field-type.cc", "src/objects/fixed-array.cc", @@ -6014,6 +6120,7 @@ v8_source_set("v8_base_without_compiler") { "src/objects/js-atomics-synchronization.cc", "src/objects/js-break-iterator.cc", "src/objects/js-collator.cc", + "src/objects/js-data-object-builder.cc", "src/objects/js-date-time-format.cc", "src/objects/js-display-names.cc", "src/objects/js-disposable-stack.cc", @@ -6086,6 +6193,7 @@ v8_source_set("v8_base_without_compiler") { "src/profiler/cpu-profiler.cc", "src/profiler/heap-profiler.cc", "src/profiler/heap-snapshot-generator.cc", + "src/profiler/output-stream-writer.cc", "src/profiler/profile-generator.cc", "src/profiler/profiler-listener.cc", "src/profiler/profiler-stats.cc", @@ -6158,6 +6266,7 @@ v8_source_set("v8_base_without_compiler") { "src/sandbox/sandbox.cc", "src/sandbox/sandboxable-thread.cc", "src/sandbox/testing.cc", + "src/sandbox/trap-fuzzer.cc", "src/sandbox/trusted-pointer-scope.cc", "src/sandbox/trusted-pointer-table.cc", "src/snapshot/code-serializer.cc", @@ -6606,6 +6715,7 @@ v8_source_set("v8_base_without_compiler") { "src/codegen/riscv/extension-riscv-f.cc", "src/codegen/riscv/extension-riscv-m.cc", "src/codegen/riscv/extension-riscv-v.cc", + "src/codegen/riscv/extension-riscv-zfa.cc", "src/codegen/riscv/extension-riscv-zfh.cc", "src/codegen/riscv/extension-riscv-zicond.cc", "src/codegen/riscv/extension-riscv-zicsr.cc", @@ -6652,6 +6762,7 @@ v8_source_set("v8_base_without_compiler") { "src/codegen/riscv/extension-riscv-f.cc", "src/codegen/riscv/extension-riscv-m.cc", "src/codegen/riscv/extension-riscv-v.cc", + "src/codegen/riscv/extension-riscv-zfa.cc", "src/codegen/riscv/extension-riscv-zfh.cc", "src/codegen/riscv/extension-riscv-zicond.cc", "src/codegen/riscv/extension-riscv-zicsr.cc", @@ -6724,11 +6835,10 @@ v8_source_set("v8_base_without_compiler") { if (v8_fuzzilli) { sources += [ - "src/fuzzilli/cov.cc", - "src/fuzzilli/cov.h", "src/fuzzilli/fuzzilli.cc", "src/fuzzilli/fuzzilli.h", ] + public_deps += [ ":fuzzilli_cov" ] } if (v8_dumpling) { @@ -6964,8 +7074,8 @@ v8_component("v8_libbase") { "src/base/compiler-specific.h", "src/base/container-utils.h", "src/base/contextual.h", - "src/base/cpu.cc", - "src/base/cpu.h", + "src/base/cpu/cpu.cc", + "src/base/cpu/cpu.h", "src/base/debug/stack_trace.cc", "src/base/debug/stack_trace.h", "src/base/discriminated-union.h", @@ -7097,6 +7207,22 @@ v8_component("v8_libbase") { "src/base/vlq.h", ] + if (target_cpu == "x86" || target_cpu == "x64") { + sources += [ "src/base/cpu/cpu-x86.cc" ] + } else if (target_cpu == "arm" || target_cpu == "arm64") { + sources += [ "src/base/cpu/cpu-arm.cc" ] + } else if (target_cpu == "riscv64") { + sources += [ "src/base/cpu/cpu-riscv.cc" ] + } else if (target_cpu == "loong64") { + sources += [ "src/base/cpu/cpu-loong64.cc" ] + } else if (target_cpu == "mips64" || target_cpu == "mips64el") { + sources += [ "src/base/cpu/cpu-mips64.cc" ] + } else if (target_cpu == "ppc64") { + sources += [ "src/base/cpu/cpu-ppc.cc" ] + } else if (target_cpu == "s390x") { + sources += [ "src/base/cpu/cpu-s390.cc" ] + } + configs = [ ":internal_config_base" ] public_configs = [ ":libbase_config" ] @@ -7395,22 +7521,18 @@ v8_source_set("fuzzer_support") { v8_source_set("v8_bigint") { sources = [ + "src/bigint/bigint-inl.h", "src/bigint/bigint-internal.cc", "src/bigint/bigint-internal.h", "src/bigint/bigint.h", - "src/bigint/bitwise.cc", - "src/bigint/digit-arithmetic.h", "src/bigint/div-burnikel.cc", - "src/bigint/div-helpers.cc", - "src/bigint/div-helpers.h", + "src/bigint/div-helpers-inl.h", "src/bigint/div-schoolbook.cc", "src/bigint/fromstring.cc", "src/bigint/mul-karatsuba.cc", - "src/bigint/mul-schoolbook.cc", "src/bigint/tostring.cc", "src/bigint/util.h", - "src/bigint/vector-arithmetic.cc", - "src/bigint/vector-arithmetic.h", + "src/bigint/vector-arithmetic-inl.h", ] if (v8_advanced_bigint_algorithms) { @@ -7561,7 +7683,7 @@ v8_header_set("cppgc_headers") { public_deps = [ ":v8_config_headers" ] } -v8_source_set("cppgc_base") { +v8_cluster_source_set("cppgc_base") { visibility = [ ":*" ] sources = [ @@ -7661,6 +7783,10 @@ v8_source_set("cppgc_base") { "src/heap/cppgc/write-barrier.h", ] + exclude_from_cluster = [ + "src/heap/cppgc/concurrent-marker.cc", # kDefaultDeadlineCheckInterval. + ] + if (cppgc_enable_caged_heap) { sources += [ "src/heap/cppgc/caged-heap-local-data.cc", @@ -8006,11 +8132,19 @@ group("v8_python_base") { data = [ ".vpython3" ] } +# Enable fallbacks for files that might be hard to access on Clusterfuzz. +copy("v8_clusterfuzz_fallbacks") { + testonly = true + sources = [ "test/mjsunit/wasm/wasm-module-builder.js" ] + outputs = [ "$root_out_dir/test/mjsunit/wasm/wasm-module-builder.js" ] +} + group("v8_clusterfuzz") { testonly = true deps = [ ":d8", + ":v8_clusterfuzz_fallbacks", ":v8_simple_inspector_fuzzer", "tools/clusterfuzz/trials:v8_clusterfuzz_resources", ] @@ -8697,6 +8831,24 @@ if (!build_with_chromium && v8_use_perfetto) { } } # if (!build_with_chromium && v8_use_perfetto) +if (v8_fuzzilli) { + v8_source_set("fuzzilli_cov") { + visibility = [ "*" ] + sources = [ + "src/fuzzilli/cov.cc", + "src/fuzzilli/cov.h", + ] + configs = [ + ":internal_config_base", + ":internal_config", + ] + deps = [ + ":v8_internal_headers", + ":v8_libbase", + ] + } +} + # GN evaluates each .gn file once per toolchain, so restricting to default # toolchain will ensure write_file() is called only once. if (current_toolchain == default_toolchain) { @@ -8710,3 +8862,4 @@ if (current_toolchain == default_toolchain) { write_file("$root_build_dir/gn_logs.txt", _lines) } +# LINT.ThenChange(BUILD.bazel) diff --git a/deps/v8/COMMON_OWNERS b/deps/v8/COMMON_OWNERS index 87e36677744ae4..eab55246360ad4 100644 --- a/deps/v8/COMMON_OWNERS +++ b/deps/v8/COMMON_OWNERS @@ -23,6 +23,7 @@ manoskouk@chromium.org marja@chromium.org mliedtke@chromium.org mlippautz@chromium.org +mrcvtl@chromium.org nicohartmann@chromium.org nikolaos@chromium.org olivf@chromium.org diff --git a/deps/v8/DEPS b/deps/v8/DEPS index 5dd3a777e4f357..306c93f226db1e 100644 --- a/deps/v8/DEPS +++ b/deps/v8/DEPS @@ -6,10 +6,15 @@ use_relative_paths = True gclient_gn_args_file = 'build/config/gclient_args.gni' gclient_gn_args = [ + 'android_ndk_version', 'checkout_src_internal', ] vars = { + # The version of the NDK. Set here, to allow the autoroller to update this + # value when updating the CIPD hash. + 'android_ndk_version': Str('2@30.0.14608247'), + # Fetches only the SDK boot images which match at least one of the whitelist # entries in a comma-separated list. # @@ -30,6 +35,11 @@ vars = { 'checkout_instrumented_libraries': False, 'checkout_ittapi': False, + # Checkout extra benchmarks. + 'checkout_benchmarks': False, + + # Fetch the internal v8 perf repository for additional benchmarks. + 'checkout_v8_perf': False, # Fetch the prebuilt binaries for llvm-cov and llvm-profdata. Needed to # process the raw profiles produced by instrumented targets (built with @@ -47,6 +57,7 @@ vars = { 'android_url': 'https://android.googlesource.com', 'chromium_url': 'https://chromium.googlesource.com', + 'chrome_internal_url': 'https://chrome-internal.googlesource.com', 'download_gcmole': False, 'download_jsfunfuzz': False, 'download_prebuilt_bazel': False, @@ -78,30 +89,33 @@ vars = { # This variable is overrided in Chromium's DEPS file. 'build_with_chromium': False, + # Repository URL + 'chromium_jetstream_git': 'https://chromium.googlesource.com/external/github.com/WebKit/JetStream.git', + # GN CIPD package version. - 'gn_version': 'git_revision:103f8b437f5e791e0aef9d5c372521a5d675fabb', + 'gn_version': 'git_revision:d830369a8e7db2383ab7bb1c2c142ee2766cfea2', # ninja CIPD package version # https://chrome-infra-packages.appspot.com/p/infra/3pp/tools/ninja 'ninja_version': 'version:3@1.12.1.chromium.4', # siso CIPD package version - 'siso_version': 'git_revision:dc540b292de5e5cbfc88bbdd15b30b1634979823', + 'siso_version': 'git_revision:8629cde6728d25cde0f6fc1e6ae6b5886e0ebe41', # Three lines of non-changing comments so that # the commit queue can handle CLs rolling Fuchsia sdk # and whatever else without interference from each other. - 'fuchsia_version': 'version:30.20251218.4.1', + 'fuchsia_version': 'version:31.20260416.4.1', # Three lines of non-changing comments so that # the commit queue can handle CLs rolling partition_alloc_version # and whatever else without interference from each other. - 'partition_alloc_version': '936619c71ecb17c0e2482cf86be3f3f417b2f683', + 'partition_alloc_version': 'fafdd4c9f559c6d0cfdf2ed3170ce370b59bfdbf', # Three lines of non-changing comments so that # the commit queue can handle CLs rolling android_sdk_build-tools_version # and whatever else without interference from each other. - 'android_sdk_build-tools_version': '-jLl4Ibk_WmgTsZaP-ueQwZDhBwkWf5BsQ4UNrkzXF0C', + 'android_sdk_build-tools_version': 'febJrTgiK9s1ANoUlc4Orn3--zs9GjGCj2vQc8g7OaMC', # Three lines of non-changing comments so that # the commit queue can handle CLs rolling android_sdk_emulator_version # and whatever else without interference from each other. @@ -113,18 +127,22 @@ vars = { # Three lines of non-changing comments so that # the commit queue can handle CLs rolling android_sdk_platforms_version # and whatever else without interference from each other. - 'android_sdk_platforms_version': 'gxwLT70eR_ObwZJzKK8UIS-N549yAocNTmc0JHgO7gUC', + 'android_sdk_platforms_version': 'WhtP32Q46ZHdTmgCgdauM3ws_H9iPoGKEZ_cPggcQ6wC', # Three lines of non-changing comments so that # the commit queue can handle CLs rolling android_sdk_tools-lint_version # and whatever else without interference from each other. 'android_sdk_cmdline-tools_version': 'gekOVsZjseS1w9BXAT3FsoW__ByGDJYS9DgqesiwKYoC', + # Three lines of non-changing comments so that + # the commit queue can handle CLs rolling jetstream_3.0-custom_revision + # and whatever else without interference from each other. + 'jetstream_3.0-custom_revision': '2145cedef4ca2777b792cb0059d3400ee2a6153c', } deps = { 'build': - Var('chromium_url') + '/chromium/src/build.git' + '@' + '483cecced32ce8b098d65eb08eb77925afa90bec', + Var('chromium_url') + '/chromium/src/build.git' + '@' + '1a96aee6e4cadad50a9deaa57b7e4af31499ceba', 'buildtools': - Var('chromium_url') + '/chromium/src/buildtools.git' + '@' + '6a18683f555b4ac8b05ac8395c29c84483ac9588', + Var('chromium_url') + '/chromium/src/buildtools.git' + '@' + 'c9110ba7150d93134b1c85ea392033b4a82d28f7', 'buildtools/linux64': { 'packages': [ { @@ -165,12 +183,21 @@ deps = { 'dep_type': 'cipd', 'condition': '(host_os == "linux" or host_os == "mac" or host_os == "win") and host_cpu != "s390x" and host_os != "zos" and host_cpu != "ppc64" and (host_cpu != "arm64" or host_os == "mac")', }, + # TODO(498118202): Use checkout_benchmarks here too. 'test/benchmarks/data': Var('chromium_url') + '/v8/deps/third_party/benchmarks.git' + '@' + '05d7188267b4560491ff9155c5ee13e207ecd65f', + 'test/benchmarks/JetStream3': { + 'url': Var('chromium_jetstream_git') + '@' + Var('jetstream_3.0-custom_revision'), + 'condition': 'checkout_benchmarks', + }, + 'third_party/v8-perf': { + 'url': Var('chrome_internal_url') + '/v8/v8-perf.git' + '@' + 'HEAD', + 'condition': 'checkout_v8_perf', + }, 'test/mozilla/data': Var('chromium_url') + '/v8/deps/third_party/mozilla-tests.git' + '@' + 'f6c578a10ea707b1a8ab0b88943fe5115ce2b9be', 'test/test262/data': - Var('chromium_url') + '/external/github.com/tc39/test262.git' + '@' + 'dd6138f9bc1aa2c3ba9cbf54452049b9a92c4e13', + Var('chromium_url') + '/external/github.com/tc39/test262.git' + '@' + 'd5e73fc8d2c663554fb72e2380a8c2bc1a318a33', 'third_party/android_platform': { 'url': Var('chromium_url') + '/chromium/src/third_party/android_platform.git' + '@' + 'e3919359f2387399042d31401817db4a02d756ec', 'condition': 'checkout_android', @@ -178,7 +205,7 @@ deps = { 'third_party/android_sdk/public': { 'packages': [ { - 'package': 'chromium/third_party/android_sdk/public/build-tools/36.1.0', + 'package': 'chromium/third_party/android_sdk/public/build-tools/37.0.0', 'version': Var('android_sdk_build-tools_version'), }, { @@ -190,7 +217,7 @@ deps = { 'version': Var('android_sdk_platform-tools_version'), }, { - 'package': 'chromium/third_party/android_sdk/public/platforms/android-36.1', + 'package': 'chromium/third_party/android_sdk/public/platforms/android-37.0', 'version': Var('android_sdk_platforms_version'), }, { @@ -205,18 +232,18 @@ deps = { 'packages': [ { 'package': 'chromium/third_party/android_toolchain/android_toolchain', - 'version': 'KXOia11cm9lVdUdPlbGLu8sCz6Y4ey_HV2s8_8qeqhgC', + 'version': 'version:' + Var('android_ndk_version'), }, ], 'condition': 'checkout_android', 'dep_type': 'cipd', }, 'third_party/catapult': { - 'url': Var('chromium_url') + '/catapult.git' + '@' + 'ef2533747d649df4cba6756528f68751b8523f81', + 'url': Var('chromium_url') + '/catapult.git' + '@' + '5a34891efa6e41c8aca8842386b8ee528963ffdf', 'condition': 'checkout_android', }, 'third_party/clang-format/script': - Var('chromium_url') + '/external/github.com/llvm/llvm-project/clang/tools/clang-format.git' + '@' + 'c2725e0622e1a86d55f14514f2177a39efea4a0e', + Var('chromium_url') + '/external/github.com/llvm/llvm-project/clang/tools/clang-format.git' + '@' + '08cce2b81a4d9801ebeaa8cdb43b241475a4d521', 'third_party/colorama/src': { 'url': Var('chromium_url') + '/external/colorama.git' + '@' + '3de9f013df4b470069d03d250224062e8cf15c49', 'condition': 'checkout_android', @@ -226,19 +253,19 @@ deps = { 'condition': 'checkout_android', }, 'third_party/depot_tools': - Var('chromium_url') + '/chromium/tools/depot_tools.git' + '@' + '284c5ccb591c3de4e9f71be4a4beb5d1916d5383', + Var('chromium_url') + '/chromium/tools/depot_tools.git' + '@' + 'f2f7ec41f2c170d6f1899406f11a48411760a683', 'third_party/dragonbox/src': Var('chromium_url') + '/external/github.com/jk-jeon/dragonbox.git' + '@' + 'beeeef91cf6fef89a4d4ba5e95d47ca64ccb3a44', 'third_party/fp16/src': Var('chromium_url') + '/external/github.com/Maratyszcza/FP16.git' + '@' + '3d2de1816307bac63c16a297e8c4dc501b4076df', 'third_party/fast_float/src': - Var('chromium_url') + '/external/github.com/fastfloat/fast_float.git' + '@' + 'cb1d42aaa1e14b09e1452cfdef373d051b8c02a4', + Var('chromium_url') + '/external/github.com/fastfloat/fast_float.git' + '@' + '05087a303dad9c98768b33c829d398223a649bc6', 'third_party/fuchsia-gn-sdk': { - 'url': Var('chromium_url') + '/chromium/src/third_party/fuchsia-gn-sdk.git' + '@' + '947109b3f1f40fb060e7c91df049ee53fe89d573', + 'url': Var('chromium_url') + '/chromium/src/third_party/fuchsia-gn-sdk.git' + '@' + '1b201add6776a68bcb7b7e01e9d5a1ded7548d83', 'condition': 'checkout_fuchsia', }, 'third_party/simdutf': - Var('chromium_url') + '/chromium/src/third_party/simdutf' + '@' + '93b35aec29256f705c97f675fe4623578bd7a395', + Var('chromium_url') + '/chromium/src/third_party/simdutf' + '@' + 'f7356eed293f8208c40b3c1b344a50bd70971983', # Exists for rolling the Fuchsia SDK. Check out of the SDK should always # rely on the hook running |update_sdk.py| script below. 'third_party/fuchsia-sdk/sdk': { @@ -252,23 +279,23 @@ deps = { 'dep_type': 'cipd', }, 'third_party/google_benchmark_chrome': { - 'url': Var('chromium_url') + '/chromium/src/third_party/google_benchmark.git' + '@' + 'abeba5d5e6db5bdf85261045e148f1db3fdc40ad', + 'url': Var('chromium_url') + '/chromium/src/third_party/google_benchmark.git' + '@' + 'c3b654389bf74fac1f2d926d0439506f06c66751', }, 'third_party/google_benchmark_chrome/src': { - 'url': Var('chromium_url') + '/external/github.com/google/benchmark.git' + '@' + '188e8278990a9069ffc84441cb5a024fd0bede37', + 'url': Var('chromium_url') + '/external/github.com/google/benchmark.git' + '@' + '8abf1e701fbd88c8170f48fe0558247e2e5f8e7d', }, 'third_party/fuzztest': - Var('chromium_url') + '/chromium/src/third_party/fuzztest.git' + '@' + '3c8b741ed69e60949a481e3ff86c7933f65cfc2d', + Var('chromium_url') + '/chromium/src/third_party/fuzztest.git' + '@' + '49d09ce32c254347ea3c5660d2be15f04bbbcadd', 'third_party/fuzztest/src': - Var('chromium_url') + '/external/github.com/google/fuzztest.git' + '@' + '54dfec04d5c9ad1f22b08002ab6a5e2d0de77671', + Var('chromium_url') + '/external/github.com/google/fuzztest.git' + '@' + 'e05cf7baec1f21e90ee659380ad3980da8db4f30', 'third_party/googletest/src': Var('chromium_url') + '/external/github.com/google/googletest.git' + '@' + '4fe3307fb2d9f86d19777c7eb0e4809e9694dde7', 'third_party/highway/src': - Var('chromium_url') + '/external/github.com/google/highway.git' + '@' + '84379d1c73de9681b54fbe1c035a23c7bd5d272d', + Var('chromium_url') + '/external/github.com/google/highway.git' + '@' + '2607d3b5b0113992fe84d3848859eae13b3b52c1', 'third_party/icu': - Var('chromium_url') + '/chromium/deps/icu.git' + '@' + 'a86a32e67b8d1384b33f8fa48c83a6079b86f8cd', + Var('chromium_url') + '/chromium/deps/icu.git' + '@' + 'ee5f27adc28bd3f15b2c293f726d14d2e336cbd5', 'third_party/instrumented_libs': { - 'url': Var('chromium_url') + '/chromium/third_party/instrumented_libraries.git' + '@' + '69015643b3f68dbd438c010439c59adc52cac808', + 'url': Var('chromium_url') + '/chromium/third_party/instrumented_libraries.git' + '@' + 'e8cb570a9a2ee9128e2214c73417ad2a3c47780b', 'condition': 'checkout_instrumented_libraries', }, 'third_party/ittapi': { @@ -282,173 +309,173 @@ deps = { 'third_party/jsoncpp/source': Var('chromium_url') + '/external/github.com/open-source-parsers/jsoncpp.git'+ '@' + '42e892d96e47b1f6e29844cc705e148ec4856448', 'third_party/libc++/src': - Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxx.git' + '@' + '7ab65651aed6802d2599dcb7a73b1f82d5179d05', + Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxx.git' + '@' + '99457fa555797f8c5ac3c076ca288d8481d3b23a', 'third_party/libc++abi/src': Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxxabi.git' + '@' + '8f11bb1d4438d0239d0dfc1bd9456a9f31629dda', 'third_party/libpfm4': - Var('chromium_url') + '/chromium/src/third_party/libpfm4.git' + '@' + '25c29f04c9127e1ca09e6c1181f74850aa7f118b', + Var('chromium_url') + '/chromium/src/third_party/libpfm4.git' + '@' + 'd35e15a834ad4e05ba2f0a3c1a2b76fde99a0570', 'third_party/libpfm4/src': - Var('chromium_url') + '/external/git.code.sf.net/p/perfmon2/libpfm4.git' + '@' + '964baf9d35d5f88d8422f96d8a82c672042e7064', + Var('chromium_url') + '/external/git.code.sf.net/p/perfmon2/libpfm4.git' + '@' + '977a25bb3dfe45f653a6cee71ffaae9a92fc3095', 'third_party/libunwind/src': - Var('chromium_url') + '/external/github.com/llvm/llvm-project/libunwind.git' + '@' + 'ba19d93d6d4f467fba11ff20fe2fc7c056f79345', + Var('chromium_url') + '/external/github.com/llvm/llvm-project/libunwind.git' + '@' + 'a2530baf3d11013afd0f1c1941ab6bef5ba71d0a', 'third_party/llvm-libc/src': - Var('chromium_url') + '/external/github.com/llvm/llvm-project/libc.git' + '@' + 'e81e859cfb7e78e70a58c3bfce859c509f45e1da', + Var('chromium_url') + '/external/github.com/llvm/llvm-project/libc.git' + '@' + 'cb952785ccee13811f293f3c419958d1e3ddafbf', 'third_party/llvm-build/Release+Asserts': { 'dep_type': 'gcs', 'bucket': 'chromium-browser-clang', 'objects': [ { - 'object_name': 'Linux_x64/clang-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '1c3c056427ab0db261c54c8fdf7c8404ff55e3de3e550520bcb1e1660ca05aad', - 'size_bytes': 57489092, - 'generation': 1768590901063677, + 'object_name': 'Linux_x64/clang-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'f4569980affeb46176ea13dbf3e6dc7d41848c4b73207bfc143575925fca0452', + 'size_bytes': 69665364, + 'generation': 1777303543976036, 'condition': 'host_os == "linux"', }, { - 'object_name': 'Linux_x64/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'e3f568bd57c7ab199eb384153eea8cbe3c0e0604b2d8bbb158985647709a9a9c', - 'size_bytes': 14391456, - 'generation': 1768590901188932, + 'object_name': 'Linux_x64/clang-tidy-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '96589206e6a2ce6cc53d358944dd9a94e031737ccbde29bc34b01cfd6e89a4c7', + 'size_bytes': 14615752, + 'generation': 1777303544176375, 'condition': 'host_os == "linux" and checkout_clang_tidy', }, { - 'object_name': 'Linux_x64/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '8762f3c6102eae568e3ca7a287e774514846f2bb2feda4cf7dc1c33d9f5f1c8d', - 'size_bytes': 14588900, - 'generation': 1768590901246745, + 'object_name': 'Linux_x64/clangd-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '28d09748f4d4aa7e2f8ead7916c334509f34b9c3a3c91503e1f4f87f97e2dc30', + 'size_bytes': 14786968, + 'generation': 1777303544154509, 'condition': 'host_os == "linux" and checkout_clangd', }, { - 'object_name': 'Linux_x64/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '4705feac592251ad0e2e1c41c855a6ecdc728908cbb459d4f68ca57f16bc4c5e', - 'size_bytes': 2321652, - 'generation': 1768590901407256, + 'object_name': 'Linux_x64/llvm-code-coverage-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '7f2b0e1257172a14ebd4941e8c1a64358f5310f0cdc726e25394a4510613560d', + 'size_bytes': 2335816, + 'generation': 1777303544407442, 'condition': 'host_os == "linux" and checkout_clang_coverage_tools', }, { - 'object_name': 'Linux_x64/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '39d29ab3e708bcb6485181ac03123cfa3bac5b2365d5c441ab0cf5e7b25354b6', - 'size_bytes': 5802908, - 'generation': 1768590901316435, + 'object_name': 'Linux_x64/llvmobjdump-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '6942073b67c302ead820ba4296a58164480ef4facf39f9513b9dc686ce068547', + 'size_bytes': 5810800, + 'generation': 1777303544330871, 'condition': '(checkout_linux or checkout_mac or checkout_android) and host_os == "linux"', }, { - 'object_name': 'Mac/clang-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '9aff2c8f9d941be0667dc3ad3d4c3591dccd70f7a3b8e80396a623364e752eeb', - 'size_bytes': 54613288, - 'generation': 1768590902935296, + 'object_name': 'Mac/clang-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'd16a7482ae08a9176cd6e84b42b15143ffd732f0ca9f4a70190da13eadb4bc7e', + 'size_bytes': 55345892, + 'generation': 1777303608234785, 'condition': 'host_os == "mac" and host_cpu == "x64"', }, { - 'object_name': 'Mac/clang-mac-runtime-library-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '4f953afe4edebb54912719b437c78842978b0205792c069aa7529fd369d900be', - 'size_bytes': 1011040, - 'generation': 1768590912304306, + 'object_name': 'Mac/clang-mac-runtime-library-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'a90c549901fc5b350c396898da37f8fe0596ccb3217e3438d357d94956ed4576', + 'size_bytes': 1017612, + 'generation': 1777303616755309, 'condition': 'checkout_mac and not host_os == "mac"', }, { - 'object_name': 'Mac/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '62033f6ff5c1ea0a18ae581edfd1178f50ede19d84675eafb640d752e26b60ae', - 'size_bytes': 14444752, - 'generation': 1768590903234647, + 'object_name': 'Mac/clang-tidy-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'a8138299221d2500408bcbd0d8d1bde7cbf502dcfea9158326c44995b9bcc3e9', + 'size_bytes': 14560012, + 'generation': 1777303608369339, 'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clang_tidy', }, { - 'object_name': 'Mac/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '4a0365772b4eb7fe12fe595355e645f12c72255bf3f869941f2b4e5c5e2b76da', - 'size_bytes': 16398188, - 'generation': 1768590903283692, + 'object_name': 'Mac/clangd-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'b92ff0154c12b046ca7d6d92849d60bb61f658997fd7e7c6d542e8260710164b', + 'size_bytes': 15988320, + 'generation': 1777303608468489, 'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clangd', }, { - 'object_name': 'Mac/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '1c307bb206c5fc1e79deec1d12ce4ead53fa41574729deaa6d2b3a67f9540710', - 'size_bytes': 2352620, - 'generation': 1768590903522922, + 'object_name': 'Mac/llvm-code-coverage-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '5e96216c1314699bc156a43cc6717be0d1af64a7017c0647f888cbcbfa477372', + 'size_bytes': 2381000, + 'generation': 1777303608547586, 'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clang_coverage_tools', }, { - 'object_name': 'Mac/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '83767300f93707ba9a40d3d7e14f1149aaf587d5c1e3ae243be8742a008e5052', - 'size_bytes': 5682364, - 'generation': 1768590903341073, + 'object_name': 'Mac/llvmobjdump-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '11509747fd87595640a29c665fa208a307c2ef2107627d4fb84f1863fb8d8433', + 'size_bytes': 5711948, + 'generation': 1777303608507636, 'condition': 'host_os == "mac" and host_cpu == "x64"', }, { - 'object_name': 'Mac_arm64/clang-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '5475c6c38a6199276ff173665a27ab608aadb3118ac34f1a75391ee6dc226798', - 'size_bytes': 45585568, - 'generation': 1768590913838191, + 'object_name': 'Mac_arm64/clang-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'e965a78a20b2281c36441d2e64d7ea4bd102aec31cabe1bcdd07125f388fa748', + 'size_bytes': 46115456, + 'generation': 1777303618366540, 'condition': 'host_os == "mac" and host_cpu == "arm64"', }, { - 'object_name': 'Mac_arm64/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '9893644917db71d520832ea9e276a98e2051acf53458efc6834973e076c6d36e', - 'size_bytes': 12429560, - 'generation': 1768590913986547, + 'object_name': 'Mac_arm64/clang-tidy-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '6b06455f4c39ef13e48397d61a4fbc52e5ba07c641ec8169449176492a392c19', + 'size_bytes': 12637640, + 'generation': 1777303618652000, 'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clang_tidy', }, { - 'object_name': 'Mac_arm64/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'e67cfb9503c442bd29642b3a42b36c283346371b8143c81b895684df0fb09e69', - 'size_bytes': 12817084, - 'generation': 1768590914107805, + 'object_name': 'Mac_arm64/clangd-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '98aa6babb6d88311267894b9941833b23e9ed98572b90ec92115547ffee4e28c', + 'size_bytes': 12966724, + 'generation': 1777303618762277, 'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clangd', }, { - 'object_name': 'Mac_arm64/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '5f17c695f24eadcc51edc720a5b0b2f2cc36413552038d93ae2bf361667d780a', - 'size_bytes': 1978756, - 'generation': 1768590914351005, + 'object_name': 'Mac_arm64/llvm-code-coverage-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '9ab7a894abf2384e2ca8c6cc7f766cf9a255c0841c72ad6cb57218b4f1f7307b', + 'size_bytes': 1993444, + 'generation': 1777303618912425, 'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clang_coverage_tools', }, { - 'object_name': 'Mac_arm64/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '5fd7fc88f00197a710aac7dd00a2b6947d5231c53a472ed38e1af0b9088cefc3', - 'size_bytes': 5418172, - 'generation': 1768590914206466, + 'object_name': 'Mac_arm64/llvmobjdump-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'c79bbc132f090114bc7433a6220213405228a6ce54863980b502ac55fb386aa0', + 'size_bytes': 5443388, + 'generation': 1777303618786920, 'condition': 'host_os == "mac" and host_cpu == "arm64"', }, { - 'object_name': 'Win/clang-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'de6622ec6d9d22b00316c47b2eb59e6cb7dbcb2d5b59f04f18c94714d0b35066', - 'size_bytes': 48839256, - 'generation': 1768590925760667, + 'object_name': 'Win/clang-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '59fc6ee76a25ddea978d844f691c9d1330b1f77ba1d8e700836a48456360dd69', + 'size_bytes': 50204436, + 'generation': 1777303629147757, 'condition': 'host_os == "win"', }, { - 'object_name': 'Win/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'bf6f38e7f5d06c8c3eff9ba85df1ddd1006828cc72b638d22a3e7562507a8a51', - 'size_bytes': 14353272, - 'generation': 1768590926006423, + 'object_name': 'Win/clang-tidy-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': 'fbb6c506bf79c719d6b2c78ff0a2dbb61fa597f1afc9868cbb0e06a98643fc4f', + 'size_bytes': 14712488, + 'generation': 1777303629264703, 'condition': 'host_os == "win" and checkout_clang_tidy', }, { - 'object_name': 'Win/clang-win-runtime-library-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'ad0dc3c686f63f40a35bd7a10f90935d08bcd9d1f23549c87cbdeb8cb503250c', - 'size_bytes': 2540656, - 'generation': 1768590935148812, + 'object_name': 'Win/clang-win-runtime-library-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '523ce5599e20920d27cdda3a9deadb860654a6aaeb60b2950836635bcd1e3574', + 'size_bytes': 2611832, + 'generation': 1777303637843461, 'condition': 'checkout_win and not host_os == "win"', }, { - 'object_name': 'Win/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'bcf731c6ce9050067212fc4164893ce768809d73732459f2c1a0ddb8f124f5f2', - 'size_bytes': 14736740, - 'generation': 1768590926034327, + 'object_name': 'Win/clangd-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '7a439e1d6444e64122bab28f75bd0211d38fe9f0909b90c28b085a74a5ffaeef', + 'size_bytes': 15086312, + 'generation': 1777303629352280, 'condition': 'host_os == "win" and checkout_clangd', }, { - 'object_name': 'Win/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': 'bf86ab13e378a70f953d014cc7a37714dbaca0d8002cd638dd4d88df08231910', - 'size_bytes': 2416448, - 'generation': 1768590926285418, + 'object_name': 'Win/llvm-code-coverage-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '3343c2b8668a8385dbf46bb4e68edb2b2e1ebe47b63390d66fe095c7675db868', + 'size_bytes': 2499180, + 'generation': 1777303629576555, 'condition': 'host_os == "win" and checkout_clang_coverage_tools', }, { - 'object_name': 'Win/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz', - 'sha256sum': '3ee3ece3cf0afa3536c39b15f818e5eab1ac4408cd31ad0ad82414d3a8aa1eca', - 'size_bytes': 5796552, - 'generation': 1768590926109316, + 'object_name': 'Win/llvmobjdump-llvmorg-23-init-10931-g20b6ec66-3.tar.xz', + 'sha256sum': '43dc69637a860f6a0b6a63c4e1308830e6c61532dac486ec97ab5ab325da8c25', + 'size_bytes': 5862768, + 'generation': 1777303629459930, 'condition': '(checkout_linux or checkout_mac or checkout_android) and host_os == "win"', }, ], @@ -472,9 +499,9 @@ deps = { 'condition': 'not build_with_chromium', }, 'third_party/perfetto': - Var('chromium_url') + '/external/github.com/google/perfetto.git' + '@' + '1d9994a93c6ada2fb261dc72984fa07683a6c86e', + Var('chromium_url') + '/external/github.com/google/perfetto.git' + '@' + 'f3bc3ed96c3e2070dcd9997b75b971823276be36', 'third_party/protobuf': - Var('chromium_url') + '/chromium/src/third_party/protobuf.git' + '@' + 'ddf513ccaeed6b1316bc2029b10f4436ad297324', + Var('chromium_url') + '/chromium/src/third_party/protobuf.git' + '@' + 'a7626b4d3bc993ea025d82e6a19cabb0ef0c53b8', 'third_party/re2/src': Var('chromium_url') + '/external/github.com/google/re2.git' + '@' + '972a15cedd008d846f1a39b2e88ce48d7f166cbd', 'third_party/requests': { @@ -482,41 +509,41 @@ deps = { 'condition': 'checkout_android', }, 'tools/rust': - Var('chromium_url') + '/chromium/src/tools/rust' + '@' + 'd2fadac996be252abe5077583a42970163e9f2e7', + Var('chromium_url') + '/chromium/src/tools/rust' + '@' + 'f13c183867e47e6d42c163a49def280d0b8eca36', 'tools/win': - Var('chromium_url') + '/chromium/src/tools/win' + '@' + 'baacfc6d5986b07abe0503216b491e234b94ba79', + Var('chromium_url') + '/chromium/src/tools/win' + '@' + 'd16e6b55b2bd699735919d8a13a55ff284086603', 'third_party/rust': - Var('chromium_url') + '/chromium/src/third_party/rust' + '@' + '975d090feeca96ede3442405f8d55a841c4652b6', + Var('chromium_url') + '/chromium/src/third_party/rust' + '@' + '2b055f4ecac78bbf34a0d34217c699b7b09b44dd', 'third_party/rust-toolchain': { 'dep_type': 'gcs', 'bucket': 'chromium-browser-clang', 'objects': [ { - 'object_name': 'Linux_x64/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz', - 'sha256sum': 'd31bf65845992926dc6dedce43348e48fd9140f5339c678974481a1e3b356da1', - 'size_bytes': 267004352, - 'generation': 1769079787385484, + 'object_name': 'Linux_x64/rust-toolchain-4c4205163abcbd08948b3efab796c543ba1ea687-2-llvmorg-23-init-10931-g20b6ec66.tar.xz', + 'sha256sum': 'a96863c5b811af23cbe3f20fcfc82939e637be2bd79f05a117f1762c3bb35fe5', + 'size_bytes': 274625900, + 'generation': 1776704596417466, 'condition': 'host_os == "linux"', }, { - 'object_name': 'Mac/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz', - 'sha256sum': '0677ec808549ab845bfdbe4ff6072d41c8b4f2c3321c68a5bf95b2577372fe34', - 'size_bytes': 254470068, - 'generation': 1769079789279846, + 'object_name': 'Mac/rust-toolchain-4c4205163abcbd08948b3efab796c543ba1ea687-2-llvmorg-23-init-10931-g20b6ec66.tar.xz', + 'sha256sum': 'cfb1cfa17fe96540ae732b2ed8cef39792786f7d84c317f3aca2004f2495c3fa', + 'size_bytes': 262623268, + 'generation': 1776704598519695, 'condition': 'host_os == "mac" and host_cpu == "x64"', }, { - 'object_name': 'Mac_arm64/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz', - 'sha256sum': '5977efd99f758004492f7e75879db85642c37b3882d610092200e850475b9042', - 'size_bytes': 238094236, - 'generation': 1769079791037848, + 'object_name': 'Mac_arm64/rust-toolchain-4c4205163abcbd08948b3efab796c543ba1ea687-2-llvmorg-23-init-10931-g20b6ec66.tar.xz', + 'sha256sum': 'f7b34f50331e3d22b9b79b8217b3645dd67700ee801bec801da09bcffb583f9c', + 'size_bytes': 245410044, + 'generation': 1776704600641512, 'condition': 'host_os == "mac" and host_cpu == "arm64"', }, { - 'object_name': 'Win/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz', - 'sha256sum': '0e4bd819cae4aa322a6f8667e3ff157adfb5eadb9d0daf615d5ff8202c530e6e', - 'size_bytes': 402509464, - 'generation': 1769079792946462, + 'object_name': 'Win/rust-toolchain-4c4205163abcbd08948b3efab796c543ba1ea687-2-llvmorg-23-init-10931-g20b6ec66.tar.xz', + 'sha256sum': 'bd99ed04453ccef4916211c6db0a7afd1185b69371e1921ebd94f9bec78af73e', + 'size_bytes': 413531112, + 'generation': 1776704602737316, 'condition': 'host_os == "win"', }, ], @@ -532,17 +559,17 @@ deps = { 'condition': 'not build_with_chromium and host_cpu != "s390x" and host_os != "zos" and host_cpu != "ppc64"', }, 'third_party/zlib': - Var('chromium_url') + '/chromium/src/third_party/zlib.git'+ '@' + '980253c1cc835c893c57b5cfc10c5b942e10bc46', + Var('chromium_url') + '/chromium/src/third_party/zlib.git'+ '@' + '89921383f1f51331f48a2dc843403779770ea3a9', 'tools/clang': - Var('chromium_url') + '/chromium/src/tools/clang.git' + '@' + 'd651bc848c45c945ecbc0c1a372b0b781e47c991', + Var('chromium_url') + '/chromium/src/tools/clang.git' + '@' + '61150a5f1ddf6460bad3d896c1502c6a56e15311', 'tools/protoc_wrapper': Var('chromium_url') + '/chromium/src/tools/protoc_wrapper.git' + '@' + '3438d4183bfc7c0d6850e8b970204cc8189f0323', 'third_party/abseil-cpp': { - 'url': Var('chromium_url') + '/chromium/src/third_party/abseil-cpp.git' + '@' + '6d5ac0f7d3f0af5d13b78044fc31c793aa3549f8', + 'url': Var('chromium_url') + '/chromium/src/third_party/abseil-cpp.git' + '@' + '5e42a36a85a252d8cdee6c39661d2bfd9883fd5c', 'condition': 'not build_with_chromium', }, 'third_party/zoslib': { - 'url': Var('chromium_url') + '/external/github.com/ibmruntimes/zoslib.git' + '@' + '1e68de6e37efced3738a88536fccb6bbfe2d70b2', + 'url': Var('chromium_url') + '/external/github.com/ibmruntimes/zoslib.git' + '@' + '804b13554e8dd6972a591c1d6e532514fadd42a8', 'condition': 'host_os == "zos"', } } @@ -845,4 +872,5 @@ recursedeps = [ 'build', 'buildtools', 'third_party/instrumented_libs', + 'third_party/v8-perf', ] diff --git a/deps/v8/MODULE.bazel b/deps/v8/MODULE.bazel index 7d7ba53b579605..b8bf8bd29c7cd5 100644 --- a/deps/v8/MODULE.bazel +++ b/deps/v8/MODULE.bazel @@ -29,6 +29,7 @@ llvm_toolchain_repository( name = "llvm_toolchain", path = "third_party/llvm-build/Release+Asserts", config_file_content = """ +load("@rules_cc//cc:defs.bzl", "CcToolchainConfigInfo", "cc_common") load("@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl", "feature", "flag_group", "flag_set", "tool_path") def _impl(ctx): @@ -109,6 +110,7 @@ def _impl(ctx): return cc_common.create_cc_toolchain_config_info( ctx = ctx, + toolchain_identifier = "local_clang", features = features, cxx_builtin_include_directories = [ "{WORKSPACE_ROOT}/buildtools/third_party/libc++", @@ -121,7 +123,6 @@ def _impl(ctx): "{WORKSPACE_ROOT}/build/linux/debian_bullseye_amd64-sysroot/usr/include", "{WORKSPACE_ROOT}/build/linux/debian_bullseye_amd64-sysroot/usr/local/include", ], - toolchain_identifier = "local_clang", host_system_name = "local", target_system_name = "local", target_cpu = "k8", @@ -139,6 +140,7 @@ cc_toolchain_config = rule( ) """, build_file_content = """ +load("@rules_cc//cc:defs.bzl", "cc_toolchain") load(":cc_toolchain_config.bzl", "cc_toolchain_config") package(default_visibility = ["//visibility:public"]) @@ -190,3 +192,9 @@ libcxx_repository = use_repo_rule("//bazel/toolchain:libcxx_repository.bzl", "li libcxx_repository( name = "libcxx", ) + +single_version_override( + module_name = "highway", + patches = ["//bazel/patches:highway_rules_cc.patch"], + patch_strip = 1, +) diff --git a/deps/v8/OWNERS b/deps/v8/OWNERS index 546159a30b56e2..265bcceab8d497 100644 --- a/deps/v8/OWNERS +++ b/deps/v8/OWNERS @@ -20,6 +20,7 @@ per-file WATCHLISTS=file:COMMON_OWNERS # Needed by the auto_tag builder per-file WATCHLISTS=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com per-file DEPS=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com +per-file DEPS=chromium-autoroll@skia-public.iam.gserviceaccount.com per-file ...-loong64*=file:LOONG_OWNERS per-file ...-mips*=file:MIPS_OWNERS diff --git a/deps/v8/README.md b/deps/v8/README.md index 5c548542eeab8c..25f09faa218454 100644 --- a/deps/v8/README.md +++ b/deps/v8/README.md @@ -5,7 +5,7 @@ V8 is Google's open source JavaScript engine. V8 implements ECMAScript as specified in ECMA-262. -V8 is written in C++ and is used in Google Chrome, the open source +V8 is written in C++ and is used in Chromium, the open source browser from Google. V8 can run standalone, or can be embedded into any C++ application. diff --git a/deps/v8/RISCV_OWNERS b/deps/v8/RISCV_OWNERS index cf613e2627324f..a8e379d1dfa193 100644 --- a/deps/v8/RISCV_OWNERS +++ b/deps/v8/RISCV_OWNERS @@ -1,3 +1,3 @@ -kasperl@rivosinc.com +kasperl@meta.com qiuji@iscas.ac.cn yahan@iscas.ac.cn diff --git a/deps/v8/SECURITY.md b/deps/v8/SECURITY.md new file mode 100644 index 00000000000000..5dc63ab1a246a9 --- /dev/null +++ b/deps/v8/SECURITY.md @@ -0,0 +1,8 @@ +# V8 Security Policy + +V8 generally follows [Chromium's guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/security-labels.md). + +Security bugs should be reported via this [buganizer form](https://issues.chromium.org/issues/new?noWizard=true&component=1363614&template=1922342) or the [VRP program](https://bughunters.google.com/report/vrp). +You can set component to `Blink>JavaScript` (componentid: 1456824) to speed up triaging. + +See [docs/security/](docs/security/) for V8-specific policies and documentation. \ No newline at end of file diff --git a/deps/v8/WATCHLISTS b/deps/v8/WATCHLISTS index db847a31279e54..33867fb543e5a0 100644 --- a/deps/v8/WATCHLISTS +++ b/deps/v8/WATCHLISTS @@ -110,6 +110,9 @@ 'trap-handler': { 'filepath': 'src/trap-handler/', }, + 'agents': { + 'filepath': 'agents/', + }, }, 'WATCHLISTS': { @@ -189,5 +192,8 @@ 'mark@chromium.org', 'mseaborn@chromium.org', ], + 'agents': [ + 'mrcvtl@chromium.org', + ], }, } diff --git a/deps/v8/agents/.style.mdformat b/deps/v8/agents/.style.mdformat new file mode 100644 index 00000000000000..864a3098885bd8 --- /dev/null +++ b/deps/v8/agents/.style.mdformat @@ -0,0 +1 @@ +# Marker file for mdformat diff --git a/deps/v8/agents/.vpython3 b/deps/v8/agents/.vpython3 new file mode 100644 index 00000000000000..08894f452122f7 --- /dev/null +++ b/deps/v8/agents/.vpython3 @@ -0,0 +1,6 @@ +python_version: "3.11" + +wheel: < + name: "infra/python/wheels/pyyaml/${vpython_platform}" + version: "version:5.4.1.chromium.1" +> diff --git a/deps/v8/agents/OWNERS b/deps/v8/agents/OWNERS new file mode 100644 index 00000000000000..3c70cea2fd5e6a --- /dev/null +++ b/deps/v8/agents/OWNERS @@ -0,0 +1 @@ +file:../COMMON_OWNERS diff --git a/deps/v8/agents/README.md b/deps/v8/agents/README.md new file mode 100644 index 00000000000000..67e4eab695a2cf --- /dev/null +++ b/deps/v8/agents/README.md @@ -0,0 +1,33 @@ +# V8 Coding Agents + +This directory provides a centralized location for files related to AI coding +agents (e.g. `gemini-cli`) used for development within V8. + +The goal is to provide a scalable and organized way to share prompts and tools +among developers, accommodating the various environments (Linux, Mac, Windows) +and agent types in use. + +To ensure consistency across the ecosystem, the directory structure and +documentation standards (excluding V8-specific skills and extensions) mirror +those in +[Chromium's agents directory](https://source.chromium.org/chromium/chromium/src/+/main:agents/). + +## Directory Structure + +### Subagents + +On-demand expertise for specific tasks. Source files are located in +[`agents/`](agents/). + +To use them, you need to run the appropriate installation script from the +`agents/` directory: + +- **For Gemini CLI**: Run `vpython3 scripts/install_for_gemini_cli.py` to + generate the subagent files in `.gemini/agents/`. +- **For Jetski**: Run `vpython3 scripts/install_for_jetski.py` to create + symlinks in `.agents/agents/`. + +## Contributing + +Please freely add self-contained agent skills that match the format of the +existing examples. diff --git a/deps/v8/agents/agents/builder/agent.json b/deps/v8/agents/agents/builder/agent.json new file mode 100644 index 00000000000000..76a25ad8b64e5d --- /dev/null +++ b/deps/v8/agents/agents/builder/agent.json @@ -0,0 +1,5 @@ +{ + "name": "builder", + "description": "Specializes in building V8.", + "config_path": "config.yaml" +} \ No newline at end of file diff --git a/deps/v8/agents/agents/builder/config.yaml b/deps/v8/agents/agents/builder/config.yaml new file mode 100644 index 00000000000000..7d1a87f4700be2 --- /dev/null +++ b/deps/v8/agents/agents/builder/config.yaml @@ -0,0 +1,11 @@ +custom_agent: + system_prompt_sections: + - content: |- + You are a build assistant. Your goal is to compile V8 for specified configurations. You can read files and search code to understand build errors. + title: Instructions + tool_names: + - run_command + - view_file + - grep_search + - list_dir + - mcp_* diff --git a/deps/v8/agents/agents/debugger/agent.json b/deps/v8/agents/agents/debugger/agent.json new file mode 100644 index 00000000000000..2cd61be6d6b54e --- /dev/null +++ b/deps/v8/agents/agents/debugger/agent.json @@ -0,0 +1,5 @@ +{ + "name": "debugger", + "description": "Specializes in interactive debugging and crash analysis.", + "config_path": "config.yaml" +} \ No newline at end of file diff --git a/deps/v8/agents/agents/debugger/config.yaml b/deps/v8/agents/agents/debugger/config.yaml new file mode 100644 index 00000000000000..d5ab65ee34fc56 --- /dev/null +++ b/deps/v8/agents/agents/debugger/config.yaml @@ -0,0 +1,12 @@ +custom_agent: + system_prompt_sections: + - content: |- + You are a debugging assistant. Your goal is to investigate crashes and unexpected behavior using GDB and other tools. + title: Instructions + tool_names: + - run_command + - view_file + - grep_search + - list_dir + - call_mcp_tool + - mcp_* diff --git a/deps/v8/agents/agents/researcher/agent.json b/deps/v8/agents/agents/researcher/agent.json new file mode 100644 index 00000000000000..933c9a9ab3826c --- /dev/null +++ b/deps/v8/agents/agents/researcher/agent.json @@ -0,0 +1,5 @@ +{ + "name": "researcher", + "description": "Specializes in exploring the codebase and finding information.", + "config_path": "config.yaml" +} \ No newline at end of file diff --git a/deps/v8/agents/agents/researcher/config.yaml b/deps/v8/agents/agents/researcher/config.yaml new file mode 100644 index 00000000000000..544fb32319fc1e --- /dev/null +++ b/deps/v8/agents/agents/researcher/config.yaml @@ -0,0 +1,10 @@ +custom_agent: + system_prompt_sections: + - content: |- + You are a research assistant. Your goal is to find relevant code, documentation, and information in the V8 codebase and the web. You provide detailed reports with file paths and line numbers. + title: Instructions + tool_names: + - view_file + - grep_search + - list_dir + - search_web diff --git a/deps/v8/agents/agents/tester/agent.json b/deps/v8/agents/agents/tester/agent.json new file mode 100644 index 00000000000000..bc7feb78cba586 --- /dev/null +++ b/deps/v8/agents/agents/tester/agent.json @@ -0,0 +1,5 @@ +{ + "name": "tester", + "description": "Specializes in running tests and benchmarks.", + "config_path": "config.yaml" +} \ No newline at end of file diff --git a/deps/v8/agents/agents/tester/config.yaml b/deps/v8/agents/agents/tester/config.yaml new file mode 100644 index 00000000000000..de6f45cf0199c3 --- /dev/null +++ b/deps/v8/agents/agents/tester/config.yaml @@ -0,0 +1,11 @@ +custom_agent: + system_prompt_sections: + - content: |- + You are a test assistant. Your goal is to run tests and benchmarks and report results. You can read files and search code to understand test failures. + title: Instructions + tool_names: + - run_command + - view_file + - grep_search + - list_dir + - mcp_* diff --git a/deps/v8/agents/prompts/README.md b/deps/v8/agents/prompts/README.md new file mode 100644 index 00000000000000..5ee69b7ea1859d --- /dev/null +++ b/deps/v8/agents/prompts/README.md @@ -0,0 +1,27 @@ +# Prompts + +This directory contains the common prompt for V8 and template prompts to teach +agents about specific tools. Everything is intended to work with gemini-cli. + +## Creating the System Instruction Prompt + +Create a local, untracked `GEMINI.md` file in your root directory. Include +relevant prompts using the `@` syntax. For example: + +```GEMINI.md +@agents/prompts/common.md +``` + +You can confirm that prompts were successfully imported by running the `/memory +show` command in gemini-cli. + +## Known problems + +All imports must be scoped to the current prompt file. a/prompt.md can import +a/prompt2.md or a/b/prompt3.md, but cannot import c/prompt4.md. See +https://github.com/google-gemini/gemini-cli/issues/4098. + +## Contributing + +Changes to `common.md` should be done *carefully* as it's meant to be used broadly. +Use the `template/` directory to add new prompts that you want to share. diff --git a/deps/v8/GEMINI.md b/deps/v8/agents/prompts/common.md similarity index 74% rename from deps/v8/GEMINI.md rename to deps/v8/agents/prompts/common.md index a05de91ed9d0dc..a034ba6c68e62a 100644 --- a/deps/v8/GEMINI.md +++ b/deps/v8/agents/prompts/common.md @@ -167,68 +167,6 @@ Bug: 123456 - The `component` is the area of the codebase (e.g., `compiler`, `runtime`, `api`). - The `Bug:` line is important for linking to issues in the tracker at https://crbug.com/ -## Working with Torque - -Torque is a V8-specific language used to write V8 builtins and some V8 object definitions. It provides a higher-level syntax that compiles down to CSA code. - -### Key Concepts - -- **Purpose:** Simplify the creation of V8 builtins and object definitions by providing a more abstract language than writing CodeStubAssembler code directly. -- **File Extension:** `.tq` -- **Location:** Torque files are primarily located in `src/builtins` and `src/objects`. -- **Compilation:** Torque files are compiled by the `torque` compiler, which generates C++ and Code Stub Assembler (CSA) files. These generated files are placed in the `out//gen/torque-generated/` directory and then compiled as part of the normal V8 build process. - - **C++ files** `*.tq` files will generate filenames like `*-tq.inc`, `*-tq.cc`, and `*-tq-inl.inc`. Additionally, there are top-level files: - - `class-forward-declarations.h`: Forward declarations for all Torque-defined classes. - - `builtin-definitions.h`: A list of all defined builtins. - - `csa-types.h`: Type definitions for the Code Stub Assembler. - - `factory.cc` and `factory.inc`: Factory functions for creating instances of Torque-defined classes. - - `class-verifiers.h` and `.cc`: Heap object verification functions (for debug builds). - - `exported-macros-assembler.h` and `.cc`: C++ declarations and definitions for exported Torque macros. - - `objects-body-descriptors-inl.inc`: Inline definitions for object body descriptors, which define the memory layout of objects. - - `objects-printer.cc`: Object printer functions for debugging. - - `instance-types.h`: The `InstanceType` enum, used to identify object types at runtime. - - `interface-descriptors.inc`: Definitions for call interface descriptors, which manage function call conventions. - - **CSA files** These have filenames like `*-csa.cc` and `*-csa.h`. They contain the C++ code that uses the `CodeStubAssembler` API to generate the low-level implementation of builtins. - -### Syntax and Features - -- **Typescript-like Syntax:** Torque's syntax is similar to Typescript with support for functions (macros and builtins), variables, types, and control flow. -- **Macros and Builtins:** - - `macro`: Inlined functions for reusable logic. - - `builtin`: Non-inlined functions, callable from other builtins or JavaScript. -- **`extern` Keyword:** Used to call C++ defined CSA functions from Torque. This is how Torque code interfaces with the rest of the V8 codebase. -- **`transitioning` and `javascript` Keywords:** - - `transitioning`: Indicates a function can cause an object's map to change (e.g., when a property is added to a JSObject). - - `javascript`: Marks a builtin as being directly callable from JavaScript, with Javascript linkage. -- **Type System:** Torque has a strong type system that mirrors the V8 object hierarchy. This allows for compile-time type checking and safer code. -- **Labels and `goto`:** Torque uses a `labels` and `goto` system for control flow, which is particularly useful for handling exceptional cases and optimizing performance. - -### Workflow for Modifying Torque Files - -1. **Identify the relevant `.tq` file:** Builtins are in `src/builtins`, and object definitions are in `src/objects`. -2. **Modify the Torque code:** Make the necessary changes to the `.tq` file, following the existing syntax and conventions. -3. **Rebuild V8:** Run the appropriate `gm.py` command (e.g., `tools/dev/gm.py x64.release`) to recompile V8. This will automatically run the Torque compiler and build the generated C++ files. -4. **Test your changes:** Run the relevant tests to ensure that your changes are correct and have not introduced any regressions. - -### Example - -A simple Torque macro to add two SMIs might look like this: - -```torque -macro AddTwoSmis(a: Smi, b: Smi): Smi { - return a + b; -} -``` - -A more complex example showing a JavaScript-callable builtin: - -```torque -transitioning javascript builtin MyAwesomeBuiltin( - js-implicit context: NativeContext)(x: JSAny): Number { - // ... implementation ... -} -``` - ## Common Pitfalls & Best Practices - **Always format before committing:** Run `git cl format` before creating a commit to ensure your code adheres to the style guide. diff --git a/deps/v8/agents/prompts/templates/README.md b/deps/v8/agents/prompts/templates/README.md new file mode 100644 index 00000000000000..52d0beb1a33f0d --- /dev/null +++ b/deps/v8/agents/prompts/templates/README.md @@ -0,0 +1,17 @@ +# Prompt Templates + +These are prompt snippets that can be used independently or added +to a base prompt to provide specific context and functionality. + +They can be imported by a GEMINI.md file with the `@` syntax: + +```src/GEMINI.md +@agents/prompts/common.md +@agents/prompts/templates/ +``` + +or used standalone: + +```src/GEMINI.md +@agents/prompts/templates/ +``` diff --git a/deps/v8/agents/prompts/templates/modular.md b/deps/v8/agents/prompts/templates/modular.md new file mode 100644 index 00000000000000..d742391576e8b0 --- /dev/null +++ b/deps/v8/agents/prompts/templates/modular.md @@ -0,0 +1,59 @@ +# Gemini Workspace for V8 + +This is the workspace configuration for V8 when using Gemini. + +For understanding V8 concepts and structure, refer to the [v8-understanding](agents/skills/v8-understanding/SKILL.md) skill. + +Some hints: +- You are an expert C++ developer. +- V8 is shipped to users and running untrusted code; make sure that the code is absolutely correct and bug-free as correctness bugs usually lead to security issues for end users. +- V8 is providing support for running JavaScript and WebAssembly on the web. As such, it is critical to aim for best possible performance when optimizing V8. + +## Subagents Setup + +To use the subagents in this repository, you need to run the appropriate installation script depending on your environment: + +- **For Gemini CLI**: Run `vpython3 agents/scripts/install_for_gemini_cli.py` to generate the subagent files in `.gemini/agents/`. +- **For Jetski**: Run `vpython3 agents/scripts/install_for_jetski.py` to create symlinks in `.agents/agents/`. + +## Workspace Subagents + +Detailed information has been moved to specialized subagents in `agents/agents/`. Use them on demand: + +- **Researcher**: Explores the codebase and finds information. See `agents/agents/researcher/`. +- **Builder**: Compiles V8. See `agents/agents/builder/`. +- **Tester**: Runs tests and benchmarks. See `agents/agents/tester/`. +- **Debugger**: Investigates crashes using GDB. See `agents/agents/debugger/`. + +## Workspace Skills & Rules + +General guidance and reference information are available as skills or rules: + +- **Folder/Directory Structure**: Understand the layout of the V8 repository. See [v8-structure](agents/skills/v8-structure/SKILL.md). +- **Key Commands**: Find commands for building and debugging. See [v8-commands](agents/skills/v8-commands/SKILL.md). +- **Testing**: Detailed guide for running and interpreting tests. See [v8-testing](agents/skills/v8-testing/SKILL.md). +- **Best Practices**: Common pitfalls and fix proposal guidelines. See [v8_best_practices](agents/rules/v8_best_practices.md). +- **Setup**: Handles missing dependencies and configuration for V8 tools. See [v8-setup](agents/skills/v8-setup/SKILL.md). +- **Git CL Conventions**: Commit message format and usage. See [git_cl](agents/rules/git_cl.md). +- **Torque**: Expert guidance for Torque. See [torque](agents/skills/torque/SKILL.md). +- **Debugging Workflow**: Guide for issue-based debugging. See [workflow-debugging](agents/skills/workflow-debugging/SKILL.md). +- **General Debugging Workflow**: Guide for general debugging. See [workflow-general-debugging](agents/skills/workflow-general-debugging/SKILL.md). +- **Performance Workflow**: Guide for performance evaluation. See [workflow-perf](agents/skills/workflow-perf/SKILL.md). +- **Porting Guide**: Guide for porting objects to HeapObjectLayout. See [port-to-heapobjectlayout](agents/skills/port-to-heapobjectlayout/SKILL.md). +- **Agent Evaluation**: Workflow for evaluating agents. See [agent-evaluation-framework](agents/skills/agent-evaluation-framework/SKILL.md). +- **Agent Self-Improvement**: Workflow for agent self-improvement. See [agent-self-improvement](agents/skills/agent-self-improvement/SKILL.md). +- **V8 Workflow**: General workflow for V8 development. See [v8-workflow](agents/skills/v8-workflow/SKILL.md). + +## Coding and Committing + +- Always follow the style conventions used in code surrounding your changes. +- Otherwise, follow [Chromium's C++ style guide](https://chromium.googlesource.com/chromium/src/+/main/styleguide/styleguide.md). +- Use `git cl format` to automatically format your changes. +- Follow [git_cl](agents/rules/git_cl.md) for commit conventions. +- For best practices and common pitfalls, see [v8_best_practices](agents/rules/v8_best_practices.md). + +## Agent Framework + +- **Mandatory Orchestration**: For any task in V8, the agent MUST act as an Orchestrator and use the specialized subagents defined in `agents/agents/`. +- Follow the rules in `agents/rules/framework.md` and `agents/rules/execution_constraints.md`. +- This ensures efficiency, parallelism, and consistency across all tasks. diff --git a/deps/v8/agents/rules/debugging.md b/deps/v8/agents/rules/debugging.md new file mode 100644 index 00000000000000..cf2bd3ecd74d18 --- /dev/null +++ b/deps/v8/agents/rules/debugging.md @@ -0,0 +1,49 @@ +--- +name: debugging-rule +trigger: always_on +--- + +# Mandatory Debugging Workflow (ORCHESTRATION ONLY) + +When tasked with debugging a crash or investigating unexpected behavior, the main agent **MUST** adhere to the following strict constraints: + +## 1. Role Restriction: Orchestrator Only +- Delegate execution of heavy technical investigation tools to specialized subagents. +- Use subagents when running GDB (`gdb-mcp`). +- Delegate extensive searches or reading large C++ files to subagents. +- Your sole job is to **Orchestrate**, **Delegate**, and **Synthesize**. +- **Continuous Delegation**: Even after receiving reports, delegate the next investigation steps. Do not take over. +- **Aggressive Parallelization**: Do not wait for a subagent to finish or fail before spawning others for independent tasks. If a subagent reports a failure, a new hypothesis, or a new lead, immediately spawn a focused subagent to investigate that specific dimension in parallel. +- **User Interface**: Act strictly as the interface to the user. Keep them informed of high-level certainties. You may provide brief status updates on running agents. +- **Naming**: Do not refer to subagents by specific titles (e.g., "Spec Expert") in user communications. Use generic descriptions of the inquiry instead. + +## 2. Mandatory First Actions (Three Parallel Tracks) +Upon receiving a debugging task, you MUST immediately initialize the following tracks in parallel: + +### Track A: Heavy Infrastructure +- Start building (`gm.py`) and preparing for runtime analysis (`gdb-mcp` or `rr`) immediately. + +### Track B: Conceptual Triage +- **JS Source Reading**: Analyze the reproducing JS script to identify language features (e.g., closures, `eval`, TDZ) and runtime flags/hints. +- **Environment Preservation**: Preserve the original reproducing script exactly as-is without modification. If the script fails due to missing flags or appears to have invalid calls (e.g., missing `%PrepareFunctionForOptimization`), keep it unaltered and ask the user to provide the correct flags or environment. Create scratch copies for minimization or testing if needed. +- **Error Log Analysis**: Analyze error logs and stack traces to identify the failing component or assertion. + +### Track C: Static Research & Eager Delegation +- **V8/Spec Exploration**: Use your internal knowledge to start reading relevant V8 C++ code (via `code_search`) and consulting ECMAScript spec requirements simultaneously. +- **Work Branching**: PROACTIVELY spawn subagents (e.g., via `self`) for every independent dimension of the task that can be parallelized. + +## 3. Iterative Concept Discovery & Overlap Analysis +During investigation (especially via GDB or subagent reports): +- **Continuous Discovery**: If you encounter a new internal concept, spawn a subagent to research it immediately. +- **Overlap & Re-evaluation**: Actively check for overlaps between concepts. When an overlap is detected, spawn a subagent to analyze the interaction and re-evaluate previous findings. + +## 4. Synthesis & Communication +- **Proactive Updates**: Keep the user informed of key milestones (e.g., triage results, parallel task status). +- **Fix Presentation**: When a fix is proposed, **YOU MUST** present it clearly to the user immediately, explaining the rationale and how it aligns with V8 best practices. +- **Bug ID Association**: Only attach bug IDs to a CL when there is proof that the CL fixes or affects the issue. + +## 5. Subagent Coordination & Anti-Duplication +- **Centralized Routing**: The main agent MUST monitor subagent tasks to prevent duplicate investigations. +- **Cross-Pollination**: If Subagent A discovers information relevant to Subagent B, the main agent must immediately relay that information. +- **Branching**: If tasks overlap, instruct subagents to pivot to uninvestigated areas and share findings. +- **GDB Resource Management**: Avoid spawning multiple subagents running GDB concurrently unless they are explicitly investigating independent execution paths or orthogonal hypotheses. diff --git a/deps/v8/agents/rules/execution-constraints.md b/deps/v8/agents/rules/execution-constraints.md new file mode 100644 index 00000000000000..de2db0a145a9ff --- /dev/null +++ b/deps/v8/agents/rules/execution-constraints.md @@ -0,0 +1,17 @@ +--- +name: execution-constraints +trigger: always_on +--- + +# Execution Constraints & Loop Prevention + +To ensure efficient operation and prevent resource waste: +1. **No Tool Looping**: Ensure tool calls are not executed with the same arguments repeatedly. If a tool call fails or returns the same content, change your strategy (e.g., use `code_search` or `grep_search` instead of reading blindly). +2. **Surgical File Reading**: Target file reading to specific sections. Pinpoint usage using search tools first. +3. **No Browser Usage**: Rely on specialized text-based tools. Ask the user for content or guidance if a resource is inaccessible through available tools (like Buganizer MCP). +4. **Mandatory Orchestration**: For any complex task or project in V8, the agent MUST act as an Orchestrator and use the multi-layered skill framework defined in `agents/skills/`. Break down tasks and delegate to subagents to maximize parallelism. Avoid sequential execution of independent tasks. +5. **Avoid Interactive Pagers**: Always use `--no-pager` or ensure `PAGER=cat` is set when running commands that might produce long output (e.g., `git branch`, `git log`), to avoid getting stuck in a pager waiting for user input. +6. **Resuming Tasks**: When resuming a task, verify the current state (e.g., active branch, file contents) rather than assuming previous state persists. +7. **No Environment-Specific Data**: Do not commit environment-specific data. +8. **Base New Branches on Clean Upstream**: Always base new branches on a clean upstream (e.g., `origin/main`). Avoid creating spurious CLs or polluting existing CLs with unrelated changes. +9. **Verify CL Contents Before Upload**: Before running `git cl upload`, ALWAYS verify that the diff relative to upstream contains ONLY the intended changes. Use `git diff --name-only origin/main..HEAD` to check the list of files being uploaded. If unrelated files are present, remove them before uploading. diff --git a/deps/v8/agents/rules/framework.md b/deps/v8/agents/rules/framework.md new file mode 100644 index 00000000000000..02021f937caf10 --- /dev/null +++ b/deps/v8/agents/rules/framework.md @@ -0,0 +1,17 @@ +--- +name: framework-rule +trigger: always_on +--- + +# Framework Rule + +For any complex task or project, the agent MUST adhere to the multi-layered skill framework defined in `.agents/skills/`. + +## Core Directives + +1. **Mandatory Orchestration**: The main agent MUST act as an Orchestrator and Scheduler, breaking down tasks into a DAG and delegating work to subagents to maximize parallelism. +2. **Environment Awareness**: Always check the environment (`jetski` vs `gemini-cli`) and use the appropriate tools as mapped in `env-abstraction`. +3. **Workflow Specialization**: Proactively identify the type of workflow (Debugging, Performance, etc.) and activate the corresponding specialized skill. +4. **Clippy Respect**: Allow background assistants (Clippy) to operate autonomously in side worktrees, and listen to their findings without letting them modify the user's active worktree. + +This rule ensures that the agent operates like an effective team or a high-performance scheduler, avoiding sequential bottlenecks and respecting user context. diff --git a/deps/v8/agents/rules/git-cl.md b/deps/v8/agents/rules/git-cl.md new file mode 100644 index 00000000000000..edc98792972ed6 --- /dev/null +++ b/deps/v8/agents/rules/git-cl.md @@ -0,0 +1,47 @@ +--- +name: git-cl +trigger: always_on +--- + +# Git CL Conventions + +These rules ensure correct usage of the Chromium-specific `git cl` tool in V8. + +## Git Command Usage (git cl) +- **Always Format**: Run `git cl format` before creating a commit or uploading a CL. +- **Uploading to Gerrit**: + - **Always use `-t` and/or `--commit-description`** for `git cl upload` instead of the deprecated `-m` flag, to avoid interactive editors. + - **Ensure Non-Interactive Behavior**: When committing, amending, or uploading (e.g., `git cl upload`), prefix the command with `EDITOR=cat` (e.g., `EDITOR=cat git cl upload`) if there is a risk of an editor opening. + - Provide a descriptive patch message: `git cl upload -t "Brief description of what changed"`. + - **Initial Upload**: On the first upload of a new CL, use `git cl upload --commit-description=+` to set the description from the commit message. + - **Subsequent Uploads**: On subsequent uploads (new patchsets), avoid using `--commit-description=+` by default, as it can combine messages or overwrite the main description incorrectly. Preferred is omitting it unless modifying description intentionally. + - **Updating Description**: If the changes in a new patchset make the existing CL description **out-of-date** or inaccurate, you **MUST** explicitly update it by passing `--commit-description="New cohesive description content"`. + - Verify `git diff` is not empty before uploading. +- **Safeguards**: + - **ALWAYS keep CLs separate**: Use standard `git worktree` to create an isolated workspace for each independent task or CL. NEVER upload a CL from a workspace containing unrelated modifications. Always verify that the diff relative to upstream contains ONLY the intended changes before uploading. + - **Consult user on external changes**: When `git cl upload` detects external changes on Gerrit and prompts to fetch them or override, the agent MUST stop and ask the user for guidance, unless explicitly instructed otherwise. + - Before performing any CL operations, ensure you have consulted the user regarding the isolation strategy as defined in the `v8-workflow` skill (e.g., branch vs. worktree). + - Preserve the issue number when reusing a CL instead of running `git cl issue 0`. + - Before uploading, run `git cl status` to verify the Issue Description matches your task. + - Review the modified files (`git show --stat`) or run `git diff --name-only origin/main..HEAD` to ensure no unrelated files are included. If you see commits or files that are not part of your specific task, reset your branch to `origin/main` and cherry-pick only your intended commits instead of uploading. + - **Verify alignment** of the subsystem/context in `git cl status` before proceeding, and consult the user if it seems mismatched. + - For CLs intended to contain ONLY process/documentation changes, verify that no code files (e.g., `.cc`, `.h`, `.js`, `.py`) are modified using `git diff --name-only origin/main`. +- **Proactive Alert Handling**: Always run `git cl status` after uploading. If you identify failing checks or try jobs, proactively suggest addressing these alerts to the user. +- **Post-Upload**: Provide the `chromium-review.googlesource.com` link to the user. +- **Retrieving and Addressing Comments**: + - Use this rule when asked about retrieving, addressing, reviewing, or fixing comments on the current CL. + - If a CL number is specified, check first that it matches the current associated CL ID (find with `git cl issue`). + - If there is no associated CL, ask the user whether you should associate it first with `git cl issue `. + - Once associated (or if using current), fetch comments using `git cl comments`. + - Note: If you have access to a dedicated tool for reviewing comments (e.g., a Gerrit MCP tool), prefer using that instead of `git cl comments`. + +## Stacked CL Workflow +When working on a chain of dependent changes (stacked CLs): +* **Upstream Configuration**: Set the upstream of a child branch to its parent branch (e.g., `git branch --set-upstream-to=parent-branch`). The base branch at the bottom of the stack tracks `origin/main`. +* **Rebasing**: When the parent branch changes, rebase the child branch on top of the updated parent. +* **Unique Change-Ids**: Ensure each CL in the stack has a unique `Change-Id`. Make sure to remove `Change-Id` from commit messages of new CLs. + +## Helpful Commands +- Use `git cl patch ` to fetch and checkout the latest patchset of a CL. +- Use `git cl land` to land the CL after approval. +- Use `git cl desc` to view or edit the CL description. diff --git a/deps/v8/agents/rules/git-commit.md b/deps/v8/agents/rules/git-commit.md new file mode 100644 index 00000000000000..42565d27ab4c70 --- /dev/null +++ b/deps/v8/agents/rules/git-commit.md @@ -0,0 +1,28 @@ +--- +name: git-commit +trigger: always_on +--- + +# Git Commit Conventions + +These rules ensure correct formatting of commits and usage of standard Git commands in V8. + +## Commit Message Format +- **Title**: Must follow the format `[component] Title`. + - Use `[agents] title` ONLY for changes to the agent automation suite itself. +- **Description**: Provide a clear explanation of "why" and "what". Wrap lines at 72 characters. Focus on content and effects, not the process. Highlight the rationale and key non-obvious design decisions. + - Maintain a cohesive summary: Rewrite or integrate new descriptions into a cohesive summary instead of simply appending them. +- **Tone**: Use concise, declarative, and natural engineering language. +- **Tags**: All tag-like lines (e.g., `TAG=`, `BUG=`, `CONV=`) must be at the very bottom of the CL description. + - Always include `TAG=agy` and the Conversation ID for agent-generated changes. + - Ensure the `Change-Id` footer is preserved in the commit message. + - **Bug Lines**: When listing multiple bugs, limit bug listings to a maximum of 4 or 5 per line (Gerrit stops rendering them as links). If you have more, add a second `Bug:` line. + +## Git Command Usage & Avoiding Interactive Hangs +- **Ensure Non-Interactive Behavior**: Jetski cannot interact with terminal-based editors. Always run commands non-interactively. + - Bypass editors by prefixing with `EDITOR=true` (e.g., `EDITOR=true git commit --amend`). + - Use `-m` or `-F` for commit messages to avoid opening an editor. + - Use `git --no-pager` or `PAGER=cat` for commands with long output (e.g., `git branch`, `git log`). +- **Timeout for Stuck Commands**: If a git command does not show progress within 1 minute, kill the task and retry or report to the user. +- **Branching**: Create a new branch for unrelated changes. Keep changes focused and isolated to specific CLs. Preferably, inform the user about the unrelated changes and ask how they want to proceed (e.g., create new branch, discard, or hold) before uploading. +- **Base on Clean Upstream**: Base new branches on a clean upstream (e.g., `origin/main`). When creating a new worktree or branch (e.g., `git worktree add -b branch_name path origin/main`), **always explicitly specify `origin/main`** as the base commit to ensure isolation from unrelated local commits. diff --git a/deps/v8/agents/rules/torque.md b/deps/v8/agents/rules/torque.md new file mode 100644 index 00000000000000..93e1ecceeebc61 --- /dev/null +++ b/deps/v8/agents/rules/torque.md @@ -0,0 +1,17 @@ +--- +name: torque +trigger: glob +globs: src/**/*.tq +--- + +# Torque Rules + +Rules for working with Torque files. + +## Registration in BUILD.gn +- If you create a **new** `.tq` file, you **MUST** register it in the root `BUILD.gn`. +- Locate the `torque_files` list in `BUILD.gn` (Note: not `v8_torque_files`). +- Add your new file path in alphabetical order. +- *Note: Modifications to existing files do not require registration changes.* + + diff --git a/deps/v8/agents/rules/v8-best-practices.md b/deps/v8/agents/rules/v8-best-practices.md new file mode 100644 index 00000000000000..f4ab14e19c9a3d --- /dev/null +++ b/deps/v8/agents/rules/v8-best-practices.md @@ -0,0 +1,31 @@ +--- +name: v8-best-practices +trigger: always_on +--- + +# V8 Best Practices + +These are best practices for proposing fixes and general development in V8. + +## Fix Proposals + +When proposing a fix, ensure the code adheres to V8 standards: + +- **Simplicity**: Code should be as simple and direct as possible. Favor straightforward and maintainable constructs. +- **Readability**: Code must be understandable to future maintainers. +- **Structural Alignment**: Fits naturally into the existing architecture (e.g., AST Visitor pattern, Bytecode generation flow). +- **Controlled Duplication**: Prefer duplication over complex abstractions ONLY when it significantly improves clarity. +- **Optimization Preservation (Methodology)**: To maximize performance, follow this systematic approach when fixing optimization violations: + - **Trace Lifecycle**: Understand how optimized state is collected, propagated, and consumed (e.g., AST -> Bytecode -> JIT). + - **Isolate Assumptions**: Identify the specific invariant that was violated. + - **Surgical Fixes**: Address the violation without restricting valid optimized paths. + - **Flaw over Disabling**: Prioritize finding the specific logic flaw in the optimization's implementation to preserve the feature. +- **Cross-Feature Awareness**: Understand how optimizations interact with core V8 features like Lazy Compilation, Ignition bytecode generation, and TurboFan/Maglev optimizations. + +## Technical Guardrails & Guidelines + +- **Inline Functions (`-inl.h`)**: Many functions are declared as `inline` in the `.h` file, and defined in a `-inl.h` file. If you get compile errors about a missing definition, you are likely missing an `#include` for a `-inl.h` file. You can only include `-inl.h` files from other `-inl.h` files and `.cc` files. +- **Cleanup Constraint**: Keep diffs small by changing only the code intended for the task. Propose cleanups to nearby code as a separate patch to keep the current change focused. + +## General Best Practices +For general best practices regarding formatting, generated files, test configurations, header names, and forward declarations, refer to Common Pitfalls & Best Practices section. This rule file focuses on V8-specific fix proposals and technical guardrails. diff --git a/deps/v8/agents/rules/writing-skills.md b/deps/v8/agents/rules/writing-skills.md new file mode 100644 index 00000000000000..19efce8e3c1cde --- /dev/null +++ b/deps/v8/agents/rules/writing-skills.md @@ -0,0 +1,132 @@ +--- +name: writing-skills-rule +trigger: agents/**/* +--- + +# Best Practices for Writing Skills and Rules in `agents/` + +This rule applies to any addition or modification to the `agents/` directory. When creating new skills or rules, adhere to the following best practices. + +## 1. Rules vs. Skills: When to Use Which + +* **Use a Rule** when you need to enforce high-level constraints, workflow mandates, role restrictions, or high-level directives. Rules are usually "always on" or triggered by specific situations (e.g., debugging). They restrict behavior or mandate specific orchestration. +* **Use a Skill** when you need to provide a specific technical guide, procedure explanation, or reference implementation for a focused task. Skills provide step-by-step instructions or reference material for a specific domain (e.g., porting a class, using a tool). + +## 2. Structure of a Skill + +Every skill must follow this directory structure: +``` +skill-name/ +├── SKILL.md # Required: Metadata + core instructions (<500 lines) +├── scripts/ # Executable code (Python/Bash) designed as tiny CLIs +├── references/ # Supplementary context (schemas, cheatsheets) +└── assets/ # Templates or static files used in output +``` + +* **SKILL.md**: Acts as the "brain." Use it for navigation and high-level procedures. +* **References**: Link directly from `SKILL.md`. Keep them one level deep only. +* **Scripts**: Use for fragile/repetitive operations where variation is a bug. Place long-lived library code in standard repo CLI directories. + +## 3. Frontmatter Optimization + +The `name` and `description` in the frontmatter of your `SKILL.md` are the only fields that the agent sees before triggering a skill. + +* **Strict Naming**: The `name` field must be 1-64 characters, contain only lowercase letters, numbers, and hyphens (no consecutive hyphens), and must exactly match the parent directory name (e.g., `name: wiz-testing` must live in `wiz-testing/SKILL.md`). Consider using gerund form (verb + -ing) for Skill names (e.g., `processing-pdfs`). +* **Trigger-Optimized Descriptions**: (Max 1,024 characters). Describe the capability in the third person and include specific triggers and "negative triggers". Ensure descriptions do not contain XML tags. + * *Bad*: "Wiz skills." (Too vague). + * *Good*: "Creates and builds Wiz components using external Sass. Use when the user wants to update component styles or build configurations. Don't use it for external Sass styles with other frameworks." + +## 4. Progressive Disclosure and Resource Management + +Maintain a pristine context window by loading information only when needed. + +* **Keep SKILL.md Lean**: Limit the main file to <500 lines. Use it for navigation and primary procedures. +* **Use Flat Subdirectories**: Move bulky context to standard folders. Keep files exactly one level deep (e.g., `references/schema.md`, not `references/db/v1/schema.md`). +* **Keep references one level deep** from `SKILL.md` to ensure complete file reads. +* **Just-in-Time (JiT) Loading**: Explicitly instruct the agent when to read a file (e.g., "See `references/auth-flow.md` for specific error codes"). +* **Explicit Pathing**: Always use relative paths with forward slashes (`/`), regardless of the OS. Avoid Windows-style paths. +* **For Agents, Not Humans**: Omit `README.md`, `CHANGELOG.md`, or installation guides. Delete redundant logic. +* **Self-Contained**: A skill should be entirely self-contained within its directory. Maintain isolation by keeping all files internal to the skill. + +## 5. Writing Instructions for Agents + +Create instructions for LLMs instead of humans. + +* **Tone and Style**: + * **Positive Framing**: Focus on what the agent *should* do. If you must specify a constraint, provide an alternative. + * *Bad (Negative)*: "Do not use Python 2." + * *Good (Positive)*: "Always use Python 3 for new scripts." + * **Third-Person Imperative**: Frame instructions as direct commands (e.g., "Extract the text..." rather than "I will extract..."). +* **Procedural Instructions**: + * **Step-by-Step Numbering**: Define workflows as strict chronological sequences. + * **Degrees of Freedom**: Match specificity to task fragility. Use low freedom (exact commands) for fragile operations like DB migrations, and high freedom for context-dependent tasks like code reviews. +* **Precision and Terminology**: + * Use identical terminology consistently. + * Use the most specific terminology native to the domain (e.g., "template" instead of "html" in Angular). +* **Templates and Examples**: + * Provide concrete templates in `assets/` and instruct the agent to copy them. + * Provide input/output pairs to guide style and detail. +* **Intentional Modifications**: Only modify a skill when there is a concrete functional reason to do so. Avoid minor rephrasing, cosmetic cleanups, or no-op changes. + +## 6. Deterministic Scripts + +Do not write instructions in `SKILL.md` that require the agent to generate complex parsing logic or boilerplate code from scratch. + +* **Offload Fragile Tasks**: Create tested Python, Bash, or Node scripts in `scripts/` for operations like parsing complex datasets or querying databases. Instruct the agent to execute these scripts rather than generating code. +* **Graceful Error Handling**: Ensure scripts return highly descriptive, human-readable error messages on stdout/stderr so the agent can self-correct based on the output. +* **Avoid Voodoo Constants**: Document and justify configuration parameters within the scripts or references. + +## 7. Skill Validation and Evaluation + +When creating or modifying a skill, you must validate your draft before declaring it complete. If you have the capability to invoke subagents or start new conversations, use the prompts below to automate this validation. If not, perform a self-simulation of these steps. + +* **Evaluation-Driven Development**: Create evaluation scenarios before writing extensive documentation. Define baseline performance expectations. +* **Validation Workflow**: + 1. **Discovery Validation**: Invoke a subagent with the following prompt (fill in your frontmatter): + ```text + I am building an Agent Skill based on the spec. Agents will decide whether to load this skill based entirely on the YAML metadata below. + + [Paste your YAML frontmatter here] + + Based strictly on this description: + 1. Generate 3 realistic user prompts that you are 100% confident should trigger this skill. + 2. Generate 3 user prompts that sound similar but should NOT trigger this skill. + 3. Critique the description: Is it too broad? Suggest an optimized rewrite. + ``` + + 2. **Logic Validation**: Invoke a subagent with the following prompt (fill in your content): + ```text + Here is the full draft of my SKILL.md and the directory tree of its supporting files. + + [Paste your directory structure and SKILL.md here] + + Act as an autonomous agent that has just triggered this skill. Simulate your execution step-by-step based on a request to: [Insert a sample request here] + + For each step, write out your internal monologue: + 1. What exactly are you doing? + 2. Which specific file/script are you reading or running? + 3. Flag any Execution Blockers: Point out the exact line where you are forced to guess or hallucinate because my instructions are ambiguous. + ``` + + 3. **Edge Case Testing**: Invoke a subagent with the following prompt: + ```text + Act as a ruthless QA tester. Your goal is to break this skill. + + Ask me 3 to 5 highly specific, challenging questions about edge cases, failure states, or missing fallbacks in the SKILL.md. Focus on fragile operations, environment assumptions, and unsupported configurations. + + Do not fix these issues yet. Just ask the numbered questions and wait for my answer. + ``` + + +## 8. Checklist for Effective Skills + +Before finalizing a skill, verify: +* Description is specific, includes triggers, and is in third person. +* `SKILL.md` body is under 500 lines. +* File references are one level deep. +* No time-sensitive information. +* Scripts handle errors explicitly and use Unix-style paths. +* Evaluations are created and tested. +* The skill is entirely self-contained and does not reference other skills. +* Modifications are intentional and functional, avoiding cosmetic or no-op changes. + diff --git a/deps/v8/agents/scripts/analyze_brain.py b/deps/v8/agents/scripts/analyze_brain.py new file mode 100755 index 00000000000000..f932ce2dd75761 --- /dev/null +++ b/deps/v8/agents/scripts/analyze_brain.py @@ -0,0 +1,59 @@ +#!/usr/bin/env vpython3 +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +from __future__ import annotations +import json +import sys +from pathlib import Path + + +def analyze_brain(brain_id: str) -> None: + brain_dir = Path.home() / f".gemini/jetski/brain/{brain_id}" + if not brain_dir.exists(): + print(f"Brain directory {brain_dir} not found.") + return + + message_files = list(brain_dir.glob(".system_generated/messages/*.json")) + if not message_files: + print("No messages found in brain.") + return + + print( + f"Analyzing {len(message_files)} messages for potential shortcuts or flaws..." + ) + + keywords = [ + "shortcut", "skip", "lazy", "ignore", "failed", "error", "timeout", + "hardcoded", "workaround" + ] + + findings = [] + for msg_file in sorted(message_files): + try: + with msg_file.open("r") as f: + msg = json.load(f) + content = msg.get("content", "").lower() + for kw in keywords: + if kw in content: + findings.append( + f"- Found '{kw}' in message {msg['id']} from {msg['sender']}: {msg['content'][:200]}..." + ) + break + except Exception as e: + print(f"Error analyzing message {msg_file}: {e}") + pass + + if findings: + print("\n Potential shortcuts or issues detected:") + for finding in findings: + print(finding) + else: + print("\nNo obvious shortcuts or issues detected via keywords.") + + +if __name__ == "__main__": + if len(sys.argv) < 2: + print("Usage: analyze_brain.py ") + sys.exit(1) + analyze_brain(sys.argv[1]) diff --git a/deps/v8/agents/scripts/cleanup_git_task.sh b/deps/v8/agents/scripts/cleanup_git_task.sh new file mode 100644 index 00000000000000..5fe7b4c393de28 --- /dev/null +++ b/deps/v8/agents/scripts/cleanup_git_task.sh @@ -0,0 +1,19 @@ +#!/bin/bash +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +# Helper to remove worktrees and clean up after a task. + +TASK_ID=$1 +if [ -z "$TASK_ID" ]; then + echo "Usage: cleanup_git_task.sh " + exit 1 +fi + +BRANCH_NAME="task-$TASK_ID" +WORKTREE_PATH="../$BRANCH_NAME" + +echo "Removing worktree at $WORKTREE_PATH..." +git worktree remove $WORKTREE_PATH +git branch -d $BRANCH_NAME +echo "Cleanup complete." diff --git a/deps/v8/agents/scripts/get_recent_commits.py b/deps/v8/agents/scripts/get_recent_commits.py new file mode 100755 index 00000000000000..f872d635ddf374 --- /dev/null +++ b/deps/v8/agents/scripts/get_recent_commits.py @@ -0,0 +1,60 @@ +#!/usr/bin/env vpython3 +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +from __future__ import annotations +import sys +import subprocess + + +def get_recent_commits(n: int = 5) -> None: + try: + # Get the last N commits + git_log_cmd = ["git", "log", f"-n {n}", "--oneline", "--format=%H"] + result = subprocess.run( + git_log_cmd, capture_output=True, text=True, check=True) + commit_hashes = result.stdout.strip().split("\n") + + if not commit_hashes or commit_hashes == [""]: + print("No commits found.") + return + + for commit in commit_hashes: + commit = commit.strip() + if not commit: + continue + + print("=" * 80) + print(f"COMMIT HASH: {commit}") + + # Get commit message + msg_cmd = ["git", "show", "--format=%B", "-s", commit] + msg_result = subprocess.run( + msg_cmd, capture_output=True, text=True, check=True) + print("COMMIT MESSAGE:") + print(msg_result.stdout.strip()) + print("-" * 40) + + # Get diff + diff_cmd = ["git", "show", "--format=", commit] + diff_result = subprocess.run( + diff_cmd, capture_output=True, text=True, check=True) + print("DIFF:") + print(diff_result.stdout.strip()) + print("=" * 80) + print("\n") + + except subprocess.CalledProcessError as e: + print(f"Error running git commands: {e}", file=sys.stderr) + sys.exit(1) + + +if __name__ == "__main__": + n = 5 + if len(sys.argv) > 1: + try: + n = int(sys.argv[1]) + except ValueError: + print(f"Invalid argument: {sys.argv[1]}. Defaulting to 5 commits.") + + get_recent_commits(n) diff --git a/deps/v8/agents/scripts/install_for_gemini_cli.py b/deps/v8/agents/scripts/install_for_gemini_cli.py new file mode 100755 index 00000000000000..4276a3ce596f5d --- /dev/null +++ b/deps/v8/agents/scripts/install_for_gemini_cli.py @@ -0,0 +1,91 @@ +#!/usr/bin/env vpython3 +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +from __future__ import annotations + +import json +from pathlib import Path +import yaml + +FILE_PATH = Path(__file__).resolve() +repo_root = FILE_PATH.parents[2] +src_dir = FILE_PATH.parents[1] / "agents" +dest_dir = repo_root / ".gemini" / "agents" + +# 1. Check if .gemini/agents is a symlink +if dest_dir.is_symlink(): + print(f"Removing symlink at {dest_dir}") + dest_dir.unlink() + +dest_dir.mkdir(parents=True, exist_ok=True) + +for item in src_dir.iterdir(): + if not item.is_dir(): + continue + + agent_json_path = item / "agent.json" + config_yaml_path = item / "config.yaml" + + if not (agent_json_path.exists() and config_yaml_path.exists()): + print(f"Skipping {item.name}: missing agent.json or config.yaml") + continue + + with agent_json_path.open("r") as f: + agent_json = json.load(f) + with config_yaml_path.open("r") as f: + config_yaml = yaml.safe_load(f) + + name = agent_json.get("name") + description = agent_json.get("description") + + custom_agent = config_yaml.get("custom_agent", {}) + system_prompt_sections = custom_agent.get("system_prompt_sections", []) + tool_names = custom_agent.get("tool_names", []) + + # Concatenate system prompt sections + body = "" + for section in system_prompt_sections: + body += f"# {section.get('title')}\n\n{section.get('content')}\n\n" + + # Map tools to Gemini CLI names + gemini_tools = [] + for t in tool_names: + if t == "view_file": + gemini_tools.append("read_file") + elif t == "run_command": + gemini_tools.append("run_shell_command") + elif t == "list_dir": + gemini_tools.append("list_directory") + elif t == "search_web": + gemini_tools.append("google_web_search") + elif t == "call_mcp_tool": + pass + else: + gemini_tools.append(t) + + # Create frontmatter + frontmatter = { + "name": name, + "description": description, + "kind": "local", + "tools": gemini_tools, + "model": "inherit" + } + + dest_file = dest_dir / f"{name}.md" + with dest_file.open("w") as f: + f.write("---\n") + yaml.dump(frontmatter, f, default_flow_style=False) + f.write("---\n") + f.write(body) + + print(f"Installed {name}.md for Gemini CLI") + +gemini_md_path = repo_root / "GEMINI.md" +if not gemini_md_path.exists(): + with gemini_md_path.open("w") as f: + f.write("@agents/prompts/templates/modular.md\n") + print(f"Created {gemini_md_path}") +else: + print(f"Skipping {gemini_md_path} creation since it already exists.") diff --git a/deps/v8/agents/scripts/install_for_jetski.py b/deps/v8/agents/scripts/install_for_jetski.py new file mode 100755 index 00000000000000..cd301e533818d2 --- /dev/null +++ b/deps/v8/agents/scripts/install_for_jetski.py @@ -0,0 +1,70 @@ +#!/usr/bin/env python3 +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +from __future__ import annotations + +from pathlib import Path +import os.path + + +def create_symlink(src: Path, dest: Path): + try: + symlink = Path(os.path.relpath(src, dest.parent)) + dest.symlink_to(symlink) + print(f"Symlinked {src.name} to {symlink}") + except OSError as e: + print(f"Failed to create symlink for {src.name}: {e}") + + +FILE_PATH = Path(__file__).resolve() +repo_root = FILE_PATH.parents[2] +agents_src = repo_root / "agents" +agents_dest = repo_root / ".agents" + +# 1. Check if .agents is a symlink to agents +if agents_dest.is_symlink(): + target = agents_dest.readlink() + if str(target) in ("agents", str(agents_src)): + print(f"Removing symlink .agents -> {target}") + agents_dest.unlink() + +# 2. Ensure .agents is a real directory +agents_dest.mkdir(parents=True, exist_ok=True) + +# 3. Process top-level items in agents/ +for item in agents_src.iterdir(): + # Skip hidden files/dirs + if item.name.startswith("."): + continue + + dest_item = agents_dest / item.name + + if item.name not in ["agents", "skills", "rules"]: + # For other items, symlink directly + if not dest_item.exists(): + create_symlink(item, dest_item) + continue + + # Create real directory in .agents/ + dest_item.mkdir(parents=True, exist_ok=True) + + # Cleanup dead symlinks + for sub_item in dest_item.iterdir(): + if sub_item.is_symlink() and not sub_item.exists(): + print(f"Removing dead symlink {sub_item}") + sub_item.unlink() + + # Symlink individual items inside + for sub_item in item.iterdir(): + dest_sub = dest_item / sub_item.name + if not dest_sub.exists(): + create_symlink(sub_item, dest_sub) + +gemini_md_path = repo_root / "GEMINI.md" +if not gemini_md_path.exists(): + with gemini_md_path.open("w") as f: + f.write("@agents/prompts/templates/modular.md\n") + print(f"Created {gemini_md_path}") +else: + print(f"Skipping {gemini_md_path} creation since it already exists.") diff --git a/deps/v8/agents/scripts/new_git_task.sh b/deps/v8/agents/scripts/new_git_task.sh new file mode 100644 index 00000000000000..9bd43f0754ab50 --- /dev/null +++ b/deps/v8/agents/scripts/new_git_task.sh @@ -0,0 +1,19 @@ +#!/bin/bash +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +TASK_ID=$1 +if [ -z "$TASK_ID" ]; then + echo "Usage: new_git_task.sh " + exit 1 +fi + +BRANCH_NAME="task-$TASK_ID" +WORKTREE_PATH="../$BRANCH_NAME" + +echo "Creating worktree at $WORKTREE_PATH..." +git worktree add $WORKTREE_PATH main +cd $WORKTREE_PATH +git checkout -b $BRANCH_NAME + +echo "Task environment isolated at $WORKTREE_PATH" diff --git a/deps/v8/agents/skills/README.md b/deps/v8/agents/skills/README.md new file mode 100644 index 00000000000000..6c207a1d5f833f --- /dev/null +++ b/deps/v8/agents/skills/README.md @@ -0,0 +1,30 @@ +# Agent Skills + +This directory contains specialized Agent Skills for V8 development. + +Unlike general context files, skills are shared, "on-demand" expertise that +multiple AI agents (such as Gemini CLI, Claude, GitHub Copilot, etc.) can +activate when relevant to your request. + +## How to Use + +To use a skill, you must first install it into your workspace. Creating a +symlink is preferred so that the skill stays up-to-date when you sync your local +checkout: + +```bash +gemini skills link agents/skills/ --scope workspace +``` + +Once installed, your agent (e.g. the Gemini CLI when using `.gemini/skills`) +will automatically detect when a skill is relevant to your request and ask for +permission to activate it. + +## Contributing + +New skills should be self-contained within their own directory under +`agents/skills/`. Each skill requires a `SKILL.md` file at its root with a name +and description in the YAML frontmatter. + +Note that gemini-cli comes preloaded with a "skill creator" skill. Most skills +can be written or improved by asking gemini to do so. diff --git a/deps/v8/agents/skills/agent-evaluation-framework/SKILL.md b/deps/v8/agents/skills/agent-evaluation-framework/SKILL.md new file mode 100644 index 00000000000000..178dd1f08b6b08 --- /dev/null +++ b/deps/v8/agents/skills/agent-evaluation-framework/SKILL.md @@ -0,0 +1,47 @@ +--- +name: agent-evaluation-framework +description: "Workflow for evaluating and refining agent debugging capabilities using designated test cases and Swarm principles. Use when evaluating subagent performance or creating benchmarks. Do not use for regular bug fixing." +--- + +# Agent Evaluation Framework Workflow + +Use this skill to orchestrate evaluation sessions for subagents, identify procedural bottlenecks, and iteratively refine system prompts and capabilities utilizing Swarm intelligence principles. + +## 0. Preparation +- **Subagent Isolation**: Ensure that subagents spawned for evaluation do NOT utilize existing session brains or previous task knowledge. This is critical to maintain the integrity of meta-testing. +- **Worktree Pre-creation**: Create isolated git worktrees using `git worktree` for each test case beforehand. Best practice is to create worktrees as subdirectories of the V8 repository (e.g., in a `worktrees/` directory within the V8 root). Report where the worktrees were created to the user. Inside worktrees builds MUST use the tools/dev/gm.py tool INSIDE the worktree for builds (or tools/dev/setup_worktree_build.py to prepare the worktree for builds). +- **Test Injection**: Copy the target test case into the worktree (e.g., `test/mjsunit/repro.js`). +- **Remote Compilation**: Ensure worktrees are set up to compile remotely (`use_remoteexec = true` in `args.gn`) before proceeding. + +## 1. Core Directives +- **Zero Hallucination**: Do not assume a test passes or fails without executing it. +- **Worktree Enforcement**: Agents MUST operate strictly within their assigned worktree. They should NOT know the main V8 root exists. +- **Test Scope**: Meta-refinement ALWAYS uses the tests in `agent-meta-tests` only. +- **Test Immutability**: The `agent-meta-tests` directory cannot be changed. +- **Crash Verification**: Only work on test-cases that still crash. +- **Auto-Run Enforcement**: ALWAYS use `SafeToAutoRun: true` for ALL commands executed during meta-refinement. Approval must NEVER be asked of the user. +- **Immediate Termination**: Terminate any agent immediately if it modifies the main V8 repository. + +## 2. Agent Orchestration & Lifecycle Management +- **Workspace Isolation**: Ensure agents are initialized in dedicated worktrees. +- **Communication Routing**: Facilitate communication between sibling agents. Since evaluated agents operate independently, the Orchestrator/Main Agent must act as a message broker to share relevant findings and prevent duplicate work. +- **User Reporting**: Synthesize high-level progress from all evaluated agents and keep the user informed without exposing raw logs or requiring manual approvals. + +## 3. Evaluation & Divergence Analysis +- **Entry Point**: A list of historical V8 fixes and their associated reproducing scripts (e.g., from `test/mjsunit/` or Buganizer). +- **Execution**: Initialize the agent in an isolated worktree checked out to the **parent commit** of the target fix. Copy the repro script and command the agent to resolve the bug. +- **Comparison**: Upon completion, compare the agent's proposed fix with the actual historical fix. +- **Analysis**: If the solutions diverge: + - Identify where the agent's reasoning deviated from the required fix. + - Scan for "hallucinated complexity"—parts of the fix that were not logically required by the root cause but were added by the agent. + - Evaluate if the agent overlooked critical architectural invariants or spec requirements. + - **Hasty Fix Detection**: Specifically check if the agent's solution simply disabled an optimization or feature mistakenly instead of addressing the logic error. +- **Root Cause Tracing**: Manually trace the logical steps required to reach the the *correct* historical fix. Identify the exact moment/decision where the agent chose a shallow path over a deep one. + +## 4. Iterative Process Refinement & Skepticism +The ultimate goal of evaluation is to harden the agent's skepticism and reasoning depth: +- **Architectural Skepticism**: Require subagents to explicitly argue *against* a proposed fix before accepting it. Look at the problem from multiple orthogonal angles. +- **Mandatory Deep Reasoning**: If a fix feels "guessed" or lacks direct evidence from GDB/Spec logs, spawn a subagent to reason deeper about the specific invariant being violated. +- **Skill Updates**: Every evaluation session MUST conclude with a diff for relevant subsystem skills to bake in the lessons learned and prevent future failures. + +- **analyze_brain.py**: Scans agent logs for markers of shortcutting, logic failures, or divergence in reasoning. diff --git a/deps/v8/agents/skills/agent-self-improvement/SKILL.md b/deps/v8/agents/skills/agent-self-improvement/SKILL.md new file mode 100644 index 00000000000000..347fd8c417d862 --- /dev/null +++ b/deps/v8/agents/skills/agent-self-improvement/SKILL.md @@ -0,0 +1,55 @@ +--- +name: agent-self-improvement +description: "Workflow for agent self-improvement via isolated execution, evaluation, and process refinement. Use when evaluating historical bugs or self-correcting skills. Do not use for new feature development." +--- + +# Agent Self-Improvement Workflow + +Use this skill to orchestrate self-improvement sessions for agents. The workflow involves running debugging or implementation tasks in isolation, evaluating the results against known good solutions, and identifying improvements in the various layers of the system. + +## Activation Criteria +- The task involves analyzing agent behavior, evaluating agent performance on historical issues, or updating skills and rules based on past runs (meta-refinement). +- Agents should detect when they are performing self-evaluation (e.g., when asked to analyze logs of other agents or refine skills based on failures) and activate this skill. + +## 1. Core Principles +- **Isolation**: Subagents must run in isolated environments (e.g., separate git worktrees) to prevent interference and ensure realistic testing. They MUST ignore any gathered knowledge (KIs) and session brains from the outside to ensure a self-contained test-run. +- **Evaluation**: A separate evaluation agent analyzes the work of the execution agent. +- **Layered Improvement**: The goal is to identify specific procedural or knowledge gaps across tools, skills, and prompts to get to a better solution. +- **Anonymization & Generalization**: When updating skills or rules based on self-evaluation, avoid recording anything specific to the user or the detailed user's installation (e.g., local paths). +- **Process Abstraction**: Keep principles and process improvements abstract and procedural. Avoid recording specific tests used, specific issue IDs debugged, or specific components affected in the general skill files. + +## 2. Workflow: Isolated Execution +- **Trigger**: This workflow can be triggered by a new capability to test, a reported bug in agent behavior, or as a regular benchmark using existing CLs (Changelists). +- **Setup Isolation**: + - Create a separate worktree for the subagent using standard workspace tools. + - **Example (Reimposition from CL)**: If starting from an existing CL: + - Check out the **parent commit** of the CL (without the fix). + - Extract the **regression test** or reproduction script from the CL. + - Place the test in the isolated worktree. +- **Launch Subagent**: + - Spawn a subagent with the specific task (e.g., "Fix the crash reproducer in `test/mjsunit/...`"). + - The subagent should follow the standard `workflow_debugging` or relevant skill. + - The subagent operates independently and reports back its final result (code changes, analysis) when complete. + +## 3. Workflow: Evaluation +- **Trigger**: Triggered automatically after the execution subagent completes its task. +- **Launch Evaluation Agent**: + - Spawn an evaluation agent (or the main agent takes this role). + - Provide the evaluation agent with: + - The execution subagent's logs and final result. + - The reference solution (e.g., the actual good fix from the original CL). +- **Process & Result Assessment**: + - The evaluation agent compares the subagent's result with the reference solution. + - **Divergence Analysis**: + - Did the subagent find the same root cause? + - Is the proposed fix equivalent, better, or worse? + - Did the subagent take unnecessary shortcuts or hallucinate complexity? + - **Layered Improvement Analysis**: The evaluation agent must analyze how the process could be improved in the various layers to get to a better solution: + - **Tool Layer**: Did the agent lack necessary tools or misuse existing ones? + - **Skill Layer**: Did the agent fail to follow skill instructions, or are the skills missing critical advice? + - **Prompt/Orchestration Layer**: Was the initial prompt unclear, or did the orchestrator fail to coordinate effectively? + +## 4. Actionable Outcomes +- **Skill Updates**: Propose specific diffs to existing skills based on the evaluation findings. +- **Process Refinement**: Document new best practices or anti-patterns discovered during the evaluation. +- **Report**: Send a synthesized report to the main agent detailing the execution, evaluation, and proposed improvements. diff --git a/deps/v8/agents/skills/clangd-setup/SKILL.md b/deps/v8/agents/skills/clangd-setup/SKILL.md new file mode 100644 index 00000000000000..a34ca9e6aa2421 --- /dev/null +++ b/deps/v8/agents/skills/clangd-setup/SKILL.md @@ -0,0 +1,40 @@ +--- +name: clangd-setup +description: "Handles installation and configuration of clangd-mcp for V8. Use when clangd-mcp is missing or needs configuration for the current workspace. Do not use for general C++ editing." +--- + +# Clangd Setup Skill + +Use this skill when `clangd-mcp` is missing or needs configuration for the current workspace. + +## Core Principles + +- **Proactive Execution**: Do all necessary work to set up `clangd` once user approval is obtained. +- **Workspace Specific**: Configuration (`compile_commands.json`) must be generated for the specific V8 checkout. + +## Setup Workflow + +Follow these steps to ensure `clangd` is ready: + +### 1. Check and Install `clangd-mcp` +1. Check if the `clangd-mcp` server is available in the list of registered servers. +2. If not available: + - Ask the user: "Would you like me to install and configure `clangd-mcp` for this workspace?" + - If approved, proceed to installation steps if known, or ask the user for guidance on how to enable it in their specific environment. + +### 2. Generate `compile_commands.json` +`clangd` requires a compilation database to understand the codebase. + +1. **Identify Build Directory**: Check for common build directories like `out/x64.debug`, `out/x64.release`. +2. **Check for Existing File**: Check if `compile_commands.json` already exists in the identified build directory or at the project root. +3. **Generate if Missing**: If it doesn't exist, you MUST attempt to generate it. + - **Method**: Run `gn gen --export-compile-commands`. + - Example: `gn gen out/x64.debug --export-compile-commands` + - Ask the user before running the command to ensure it targets the correct build directory they are working with. + +### 3. Verify Configuration +1. Once `compile_commands.json` is generated, verify that `clangd-mcp` tools (like `find_symbol`, `get_definition`) return meaningful results for a known symbol in the codebase. + +## Troubleshooting + +- If `clangd` cannot find headers, ensure `compile_commands.json` is at the root or linked correctly, and that the build has been run at least once to generate all necessary headers (like Torque generated files). diff --git a/deps/v8/agents/skills/crossbench/SKILL.md b/deps/v8/agents/skills/crossbench/SKILL.md new file mode 100644 index 00000000000000..151cbdc303f108 --- /dev/null +++ b/deps/v8/agents/skills/crossbench/SKILL.md @@ -0,0 +1,77 @@ +--- +name: crossbench +description: "Running benchmarks with Crossbench." +--- + +# Crossbench + +Crossbench is the central chrome runner harness for press benchmarks like +JetStream, Speedometer or Motionmark, as well as for loading live pages. + +## Location and Setup + +- **Location**: It is often installed in `~/crossbench` or in + `CHROMIUM_CHECKOUT/src/tools/perf/cb`, but could be anywhere. + If not found in standard locations, ask the user for the path. +- **Update**: Always ensure you are running the latest version. + +## Basic Usage + +Navigate to the crossbench directory and use `./cb.py` directly (or via `poetry` +if vpython3 is not available). + +```bash +# Run the latest stable JetStream with a specific d8 binary +./cb.py jetstream --browser=/path/to/d8 --env-validation=warn +``` + +And for chrome: + +```bash +./cb.py jetstream --browser=out/x64.release/chrome --env-validation=warn +``` + +## Filtering + +- You can run benchmark workload separate with `--separate` for instance to + generate individual profiles for each sub test +- Use `--story=XXX` to only run a specific test + +## Crossbench MCP + +Use `./cb.py mcp` to launch a local MCP to interact with benchmarks. + +## Profiling with Probes + +- Use `./cb.py describe probes` to list all probes. +- Use `./cb.py describe probe v8.log` to show detailed help for a specific probe. + +Important probes for v8 investigation: + +- `--probe='v8.log'` to generate a `v8.log` file (see v8-log skill for + more information on how to analyse the log file) +- `--probe='profiling'` to generate a Linux `perf` trace. +- `--probe=perfetto` to collected perfetto traces + +Results: + +- Crossbench prints the results directory and provides a summary + `cb.results.json` file listing all probe results + +## Best Practices + +- Use `--env-validation=warn` to bypass environment input prompts. +- Use `./cb.py describe` to understand subcommands and probes. +- Prefer creating JSON files instead of HJSON for configurations to minimize quoting errors. +- Validate generated configs with `poetry run cb_validate_hjson -- file.hjson`. + +## Known Stories + +- Be aware that 'WSL' in JetStream3 refers to the **WebGPU Shading Language** + workload, not the Windows Subsystem for Linux environment. + +## Environment Fallbacks + +- Suggest install depot_toools if vpython3 is not available +- Use poetry as backup if vpython3 is not available. +- The JetStream benchmark can be run directly with d8 diff --git a/deps/v8/agents/skills/doc-invalidation-checker/SKILL.md b/deps/v8/agents/skills/doc-invalidation-checker/SKILL.md new file mode 100644 index 00000000000000..c0d6f193374a45 --- /dev/null +++ b/deps/v8/agents/skills/doc-invalidation-checker/SKILL.md @@ -0,0 +1,35 @@ +--- +name: doc-invalidation-checker +description: Analyzes recent commits and uses a smart AI subagent to check if they invalidate any documentation in docs/. +--- + +# Documentation Invalidation Checker + +Use this skill when you need to determine if recent commits invalidate information within the documentation in the `docs/` directory. + +## Steps to Perform Analysis + +1. **Retrieve Recent Commits**: + Execute the `get_recent_commits.py` script to fetch the recent commits with their diffs: + ```bash + agents/scripts/get_recent_commits.py 5 + ``` + +2. **Identify Relevant Documentation**: + Look at the modified files and descriptions in the commit diff. Identify which files in `docs/` discuss the modified modules or concepts. + +3. **Invoke the Subagent for AI Analysis**: + Use the `invoke_subagent` tool to call a subagent with the `pro` model tier. + Provide the subagent with: + - The commit message and diff. + - The content of the relevant file(s) from `docs/`. + +4. **Subagent Analysis Prompt**: + The subagent should receive a prompt like: + > Compare this commit diff with the documentation file `[doc_path]`. Does this commit make any statement, step, or configuration in the documentation obsolete, incorrect, or deprecated? If yes, specify exactly what section is invalidated and provide recommended text edits. + +5. **Document and Present**: + Collate the invalidation findings into a walkthrough report for update. + +## Tools Used +- **[get_recent_commits.py](../../scripts/get_recent_commits.py)**: Retrieves recent commits and their diffs. diff --git a/deps/v8/agents/skills/ecmascript/SKILL.md b/deps/v8/agents/skills/ecmascript/SKILL.md new file mode 100644 index 00000000000000..6bf40338777910 --- /dev/null +++ b/deps/v8/agents/skills/ecmascript/SKILL.md @@ -0,0 +1,124 @@ +--- +name: ecmascript evaluation +description: Evaluates JavaScript using the official ECMAScript specification +--- +# Instructions + +## Prerequisites +This skill requires the following two MCP servers from [v8-agents](https://github.com/v8/agents): +1. `ecma262`: Provides spec research and parsing tools. +2. `ecma262_state_machine`: Provides abstract machine state simulation tools. + +## 1. Role & Identity +You are the ultimate authority on the ECMAScript Language Specification (ECMA-262) and JavaScript semantics. Your purpose is to evaluate JavaScript code with absolute formal precision. +You operate as a strict, stateful abstract machine when evaluating code. + +## 2. Core Directives & Execution Protocol + +### A. Formal Code Evaluation (The Step-by-Step Protocol) + +When asked to evaluate a JavaScript snippet, you must act as the ECMAScript abstract machine. You will bridge the gap between the Syntactic Grammar and the Runtime Semantics by strictly adhering to this sequence: + +1. **Parse:** You MUST use `ecma262_parse(code)` to generate the Abstract Syntax Tree (AST) before evaluation. The parser output is cleaned to remove location data for density; use this structure to guide your evaluation precisely. +2. **Initialize State:** Initialize a JSON block in your scratchpad representing the full state of the abstract machine (including `executionContextStack`, `environmentRecords`, and `heap`). +3. **Execution Loop:** Traverse the AST. For each node, find the corresponding Runtime Semantics evaluation rules using `ecma262_search` and `ecma262_section`. **You MUST follow the specification algorithms step-by-step on your own terms.** You are forbidden from summarizing or skipping steps. You MUST provide the full step-by-step evaluation trace as required by the skill rules, maintaining the call stack and environment in your JSON state. If a step requires a choice (If/Else), evaluate the condition based on your current state and proceed with the correct branch. You must trace execution node-by-node from the AST, and ensure all identifier names and literal values in your state match the AST exactly. Do not assume names or values based on memory of similar tests. +4. **Strict Citation:** For every single step of the evaluation, explicitly cite the specific section ID and rule name (e.g., `[sec-addition-operator-plus-runtime-semantics-evaluation]`). +5. **Completion Record Handling:** Always explicitly unwrap or propagate Completion Records (`[[Type]]`, `[[Value]]`, `[[Target]]`). Pay strict attention to `ReturnIfAbrupt` shorthands (`?` and `!`). + +### B. State Management + +* **Formal Machine State:** You **MUST** maintain the state of the abstract machine (including `executionContextStack`, `environmentRecords`, and `heap`) using the provided state machine tools. You MUST accurately update the state using the provided tools for EVERY state change required by the specification. Do not just describe the state changes in text; you MUST actually call the corresponding tools to update the machine state! Furthermore, the **state history** (inspectable via `get_history`) must be correct and complete, faithfully reflecting all operations performed. Skipping tool calls will result in an incomplete and incorrect history, which is a violation of this rule. + +### C. Ambiguity +* **Identify Ambiguity:** The spec is not flawless. If you detect an editorial error, a missing indeterminate form definition, or an undefined sequence, explicitly flag it. + +## 3. Tool Usage & Orchestration SOP + +You are equipped with purpose-built MCPs. Use these tools strategically to build your answers: + +> [!IMPORTANT] +> **Strict Tool Usage Rules:** +> 1. **No Guessing Tool Names**: You MUST ONLY use the operation names listed in Section II for `object_op` and `env_op`. Do NOT assume a specification operation (like `OrdinaryFunctionCreate` or `Call`) is available as a tool unless it is explicitly listed here. +> 2. **Flat Arguments**: You MUST pass arguments as flat JSON properties to the tools. Do NOT wrap arguments in an `args` or `desc` object unless the schema explicitly requires it. + +### I. Navigation & Grammar Extraction +* `ecma262_get_operation(name)`: **[RECOMMENDED]** Use this to directly fetch the algorithm for an abstract operation by name (e.g., `ToObject`, `GetValue`, `CreateMutableBinding`). **Try this FIRST** whenever you know the name of the operation you need, as it bypasses search-then-fetch and saves steps. +* `ecma262_get_evaluation(production_name)`: **[RECOMMENDED]** Use this to directly fetch the evaluation rules for a specific grammar production (e.g., `VariableStatement`). This saves steps and is much faster than searching. +* `ecma262_search(query)`: Use this to locate the exact section ID for a syntax node (e.g., `VariableStatement`) or when you don't know the exact name of the operation. +* `ecma262_signature(name)` / `ecma262_dependencies(id)`: Use these to map out the call graph before writing out an evaluation. This ensures you know which operations you will need to invoke. +* `ecma262_section(id)`: Fetch the actual algorithm steps. Treat these steps as law. +* `ecma262_lookup(id)`: Resolves the ancestry (parent chain) of a given section ID, helping to understand its context in the specification hierarchy. +* `ecma262_sections(ids)`: Fetch full HTML content for multiple section IDs at once to reduce tool calls. +* `ecma262_production(symbol)`: Use this to fetch Syntactic or Lexical grammar rules (e.g., `StringNumericLiteral` or `AssignmentExpression`) to explain parsing edge cases. + +### II. State Alteration (JSON Scratchpad) +You **MUST** use the following tools to maintain the abstract machine state. Call `init()` at the start of evaluation. The tool will automatically generate a unique state file and remember it as the 'current' state file for your session. For all subsequent state tool calls, you can omit the `state_id` argument, and it will automatically use the current state file. + +* `init()`: Initialize the state with Global Realm, Env, and Context. Call this at the start of evaluation. It will automatically generate a unique state file. + > [!NOTE] + > `init()` initializes the state with the following well-known references: + > - Realm: `ref:Realm:1` + > - Global Object: `ref:Obj:Global` + > - Global Environment: `ref:Env:Global` + > - Global Object Record: `ref:Env:GlobalObj` + > - Global Declarative Record: `ref:Env:GlobalDecl` +* `push_context(name, realm, lexEnv, varEnv)`: Push a new execution context onto the stack. +* `pop_context()`: Pop the top execution context. +* `new_environment(type, outerEnv, bindings)`: Create a new environment record (Declarative, Function, Private, Module). +* `set_binding(envId, name, value)`: Set a binding in an environment. +* `env_op(env_id, operation, name, value)`: Performs operation on Environment Record (`CreateMutableBinding`, `CreateImmutableBinding`, `InitializeBinding`, `SetMutableBinding`, `GetBindingValue`, `DeleteBinding`, `HasBinding`, `BindThisValue`, `HasThisBinding`, `HasSuperBinding`, `GetThisBinding`, `CreateImportBinding`). +* `object_op(object_id, operation, property_name, value, descriptor)`: Performs operation on Heap / Object Model (`MakeBasicObject`, `OrdinaryObjectCreate`, `SetInternalSlot`, `OrdinaryDefineOwnProperty`, `OrdinaryGetPrototypeOf`, `OrdinarySetPrototypeOf`, `OrdinaryIsExtensible`, `OrdinaryPreventExtensions`, `OrdinaryGetOwnProperty`, `OrdinaryHasProperty`, `OrdinaryDelete`, `OrdinaryOwnPropertyKeys`, `OrdinaryGet`, `OrdinarySet`, `OrdinaryCall`, `OrdinaryConstruct`, `CreateDataProperty`, `OrdinaryFunctionCreate`, `PrivateFieldAdd`, `PrivateFieldGet`, `PrivateFieldSet`, `CreatePrivateName`, `ProxyCreate`, `ArrayCreate`, `StringCreate`). +* `update_context(key, value)`: Updates a field in the running execution context. +* `enqueue_promise_job(job_name, callback_id, args)`: Enqueues a job in the Promise Job Queue. +* `get_job_queue()`: Returns the current list of pending jobs as a JSON string. +* `dequeue_job()`: Removes and returns the first job from the queue as a JSON string. +* `get_history(format_type)`: Returns the history of the state. Supported formats are 'full' and 'diff'. + +* **Delta State Reporting:** To reduce verbosity and save context in conversation messages, you should only report the *changes* (deltas) to the state in your messages after calling a state tool, while ensuring that the *full* state is correctly updated and maintained in the state file via the tools. + +> [!IMPORTANT] +> **Private Fields Scoping & Shadowing:** +> To support private fields correctly, you MUST use `object_op` with operation `"CreatePrivateName"` to generate a unique Private Name identifier. Use this returned identifier as the key (`property_name`) in `PrivateFieldAdd`, `PrivateFieldGet`, and `PrivateFieldSet` operations. + +> [!IMPORTANT] +> **Proxies and Exotic Objects:** +> Operations like `OrdinaryGet`, `OrdinarySet`, `OrdinaryHasProperty`, and `OrdinaryDelete` act as the spec's `[[Get]]`, `[[Set]]`, `[[HasProperty]]`, and `[[Delete]]` dispatchers. +> - If they encounter a **Proxy** object, they will return a JSON object with `"status": "requires_proxy_trap"`. You MUST read this status and follow the instructions to invoke the appropriate trap on the handler object manually using `OrdinaryCall`. +> - If they encounter a **String** object, they handle indexed access natively. +> - If they encounter an **unsupported exotic object**, they will return `"status": "unsupported_exotic_object"`. You MUST read the instructions in the response and follow the spec for that operation manually! + +### III. Tool Usage Examples + +#### 1. Creating Object Literals with Methods +To create an object literal like `{ a: 1, b() { return 2; } }`: +1. Create the target object: `object_op(..., "MakeBasicObject")` -> returns `ref:Obj:1`. +2. Define data property `a`: `object_op("ref:Obj:1", "OrdinaryDefineOwnProperty", "a", descriptor={"value": 1, "writable": true, "enumerable": true, "configurable": true})`. +3. Define method `b`: + a. Create function object: `object_op(..., "MakeBasicObject", descriptor={"internalSlots": ["[[Call]]"]})` -> returns `ref:Obj:2`. + b. Define property `b` on target: `object_op("ref:Obj:1", "OrdinaryDefineOwnProperty", "b", descriptor={"value": "ref:Obj:2", "writable": true, "enumerable": false, "configurable": true})`. + +#### 2. Managing Environments and Contexts +When entering a new function or block scope: +1. Create the environment: `new_environment("Declarative", outerEnv="ref:Env:Current")` -> returns `ref:Env:5`. +2. If it's a function call, push a new context: `push_context("myFunction", "ref:Realm:1", lexEnv="ref:Env:5", varEnv="ref:Env:5")`. +3. Bind parameters or variables in the new environment using `env_op("ref:Env:5", "CreateMutableBinding", "x")` and `InitializeBinding`. +4. Upon exiting, pop the context if one was pushed: `pop_context()`. + +#### 3. Managing the Job Queue (Async/Promises) +When evaluating code that schedules microtasks: +1. Enqueue the job: `enqueue_promise_job("ResumeAsyncFunction", "ref:Obj:Callback", ["arg1"])`. +2. When the main script finishes, inspect the queue: `get_job_queue()`. +3. Dequeue the next job: `dequeue_job()`. +4. Simulate the execution of that job by pushing a new context and evaluating the closure! + +## 4. Output Formatting Rules +* Use **Markdown** extensively. +* Format code blocks using `javascript` or `ecmascript`. +* Represent spec-internal types clearly. Use double brackets for internal slots/methods and records. +* Use italics for algorithmic variables and bold for specification types. +* When you have completed the formal evaluation, you MUST output the marker `== SUMMARY ==` on its own line, followed by a summary of the execution in the prescribed format. + +## 5. System Integrity +* **Handling Undefined Functions**: Treat as `ReferenceError` unless global binding exists. +* **Do Not Assume Execution Order**: Verify exact sequence by reading the spec. +* **Look Up Before Speculating**: Always use tools to look up spec sections. diff --git a/deps/v8/agents/skills/env-abstraction/SKILL.md b/deps/v8/agents/skills/env-abstraction/SKILL.md new file mode 100644 index 00000000000000..46da7368da3274 --- /dev/null +++ b/deps/v8/agents/skills/env-abstraction/SKILL.md @@ -0,0 +1,43 @@ +--- +name: env-abstraction +description: "Handles abstraction of environment-specific commands between Jetski and Gemini-CLI. Use when switching execution context between local terminal environments. Do not use for debugging logic issues." +--- + +# Environment Abstraction Skill + +This skill provides a layer of abstraction over environment-specific tools and commands, allowing skills to be reused across different platforms like `jetski` and `gemini-cli`. + +## Core Principles + +1. **Decoupling**: Keep tool calls independent from platform specific implementations inside general workflow skills. +2. **Detection**: Determine the environment at startup (e.g., via environment variables or tool availability). +3. **Mapping**: Map abstract actions to concrete commands or tool calls based on the environment. + +## Environment Definitions + +### Jetski Environment +- **Characteristics**: Rich set of specialized tools (e.g., `code_search`, `moma_search`, `gdb-mcp`, `v8-utils`). +- **Usage**: Prefer specialized tools over generic shell commands to maximize efficiency and respect workspace constraints (e.g., avoid heavy searches in large workspaces). + +### Gemini-CLI Environment +- **Characteristics**: May rely more on standard shell commands or a different set of MCP servers. +- **Usage**: Fall back to standard tools like `grep`, `find`, or standard `gdb` via `run_command` if specialized Jetski tools are unavailable. + +## Abstract Action Mapping + +When performing common actions, refer to this mapping to choose the correct tool: + +| Abstract Action | Jetski Implementation | Gemini-CLI Implementation (Fallback) | +| :--- | :--- | :--- | +| **Code Search** | `code_search` | `grep_search` (if outside Google3) or standard `grep` | +| **File Search** | `find_by_name` (if safe) | Standard `find` or `fd` | +| **Debugging** | `gdb-mcp` | Standard `gdb` via `run_command` | +| **Building** | `tools/dev/gm.py` (use `use_remoteexec=true`) | `tools/dev/gm.py` | +| **Testing** | `tools/run-tests.py` | `tools/run-tests.py` | +| **Starting Agents** | `invoke_subagent` (tool) | `agentapi new-conversation` (CLI) | + +## Implementation Guidelines + +- When writing or updating skills, refer to actions by their abstract names. +- Check for the existence of specialized tools before falling back to generic commands. +- Document any environment-specific assumptions in the skill file. diff --git a/deps/v8/agents/skills/header-cycle-breaker/SKILL.md b/deps/v8/agents/skills/header-cycle-breaker/SKILL.md new file mode 100644 index 00000000000000..26ffd5ff185782 --- /dev/null +++ b/deps/v8/agents/skills/header-cycle-breaker/SKILL.md @@ -0,0 +1,69 @@ +--- +name: header-cycle-breaker +description: Guide for breaking cyclic dependencies in V8 headers and resolving cascade IWYU failures. +--- + +# Header Cycle Breaker Skill + +This skill outlines the systematic approach to breaking cyclic dependencies in +V8 headers, specifically focusing on moving heavy inline includes to more +localized `.cc` files or non-inline headers, and resolving the resulting cascade +of "undefined inline function" errors (IWYU - Include What You Use style). + +## When to Use + +Use this skill when: + +- You are tasked with breaking a header cycle in V8 (e.g., core-to-wasm cycle). +- You need to remove an `-inl.h` include from another `-inl.h` or `.h` file. +- You encounter a flood of `[-Werror,-Wundefined-inline]` errors after modifying + a heavy header. + +## Workflow + +### Phase 1: Identification and Cycle Breaking + +1. **Identify the cycle**: Use tools or subagents to map the include graph and + find the cyclic path. +2. **Plan the break**: Identify a point where an `-inl.h` can be replaced with + its non-inline counterpart (`.h`) or where an include can be moved entirely + to implementation files. +3. **Apply the break**: Modify the header file to break the cycle. + +### Phase 2: Resolving the Cascade (IWYU) + +Breaking a heavy include chain will cause many implementation files (`.cc`) and +even generated files to fail because they were relying on transitive includes +for inline definitions. + +1. **Do not panic**: Expect tens or hundreds of compilation errors initially. +2. **Aggressive Delegation**: Spawn subagents for independent file failures. + Prompt them to identify missing headers for specific undefined symbols. +3. **IWYU Application**: For each failing file: + - Identify which inline method is undefined. + - Find which `-inl.h` file defines it. + - Include that `-inl.h` file directly in the failing `.cc` file, preferably + within appropriate guards (e.g., `#if V8_ENABLE_WEBASSEMBLY`). +4. **Repeat until clean**: Build, fix, and build again. This is an iterative + process. + +### Phase 3: Special Case - Generated Files + +If a generated file (e.g., `objects-printer.cc`) fails with undefined inline +methods: + +1. **Trace to generator**: Realize that editing the generated file is temporary. + Find the source generator (e.g., in `src/torque/`). +2. **Modify the generator**: Update the generator code to emit the necessary + `#include` statements in the files it generates. +3. **Rebuild the generator**: Recompile the tool (e.g., Torque) and let the + build system regenerate the files. + +## Best Practices + +- **Keep files isolated**: Do not revert the cycle-breaking change when you see + cascade errors. Push through by fixing the files. +- **Use guards**: Always wrap Wasm-specific includes in + `#if V8_ENABLE_WEBASSEMBLY`. +- **Check trait caching**: Be aware of C++ trait caching issues if you encounter + weird subtyping errors during header reorganization. diff --git a/deps/v8/agents/skills/jsvu/SKILL.md b/deps/v8/agents/skills/jsvu/SKILL.md new file mode 100644 index 00000000000000..0762a806878d1e --- /dev/null +++ b/deps/v8/agents/skills/jsvu/SKILL.md @@ -0,0 +1,30 @@ +--- +name: jsvu +description: "How to use jsvu for cross-engine testing." +--- + +# JSVU (JavaScript engine Version Updater) + +Use `jsvu` to install and test across multiple JavaScript engines (e.g., v8, spidermonkey, javascriptcore, chakra). + +## Installation and Setup + +For non-interactive installation and updating of specific engines on Linux, run: + +```bash +npx jsvu --os=linux64 --engines=v8,spidermonkey,javascriptcore +``` + +You can customize the `--engines` flag with the engines you wish to test (e.g., `v8,v8-debug,spidermonkey,javascriptcore,graaljs`). + +## Running Engines + +Once installed, the engines are available in `~/.jsvu/bin/`. You can run them directly: + +```bash +~/.jsvu/bin/v8 my_test.js +~/.jsvu/bin/spidermonkey my_test.js +~/.jsvu/bin/javascriptcore my_test.js +``` + +This allows you to easily cross-reference behaviors and bugs against other major JS engines. diff --git a/deps/v8/agents/skills/orchestrator/SKILL.md b/deps/v8/agents/skills/orchestrator/SKILL.md new file mode 100644 index 00000000000000..7098ca55fb118c --- /dev/null +++ b/deps/v8/agents/skills/orchestrator/SKILL.md @@ -0,0 +1,92 @@ +--- +name: orchestrator +description: "Core skill for task scheduling and multi-agent coordination in V8 development. Use for any multi-step workflow or complex task. Do not use for simple linear tasks." +--- + +# Orchestrator Skill + +This skill defines the behavior of the Main Agent acting as an Orchestrator and Scheduler. It is mandatory for all complex tasks to ensure efficiency, parallelism, and correct dependency handling. + +## Core Responsibilities + +1. **Task Breakdown & DAG Construction**: + - Analyze the high-level goal and break it down into discrete tasks. + - Model tasks as a Directed Acyclic Graph (DAG) where edges represent dependencies. + - Maintain the DAG in the `task.md` artifact or equivalent representation. + +2. **Scheduling & Execution**: + - Identify tasks with satisfied dependencies (in-degree 0) that are ready for execution. + - Delegate ALL ready tasks to specialized subagents. The Orchestrator agent MUST NOT execute tasks (like running builds, tests, or benchmarks) directly. + - Maximize parallelism by running independent tasks concurrently. + +3. **Priority & Resource Management**: + - Assign priorities to tasks. Critical path tasks get highest priority. + - Monitor resource usage (context window, active subagents) and throttle execution if necessary. + - Handle priority inversion: if a high-priority task is blocked on a low-priority task, elevate the low-priority task. + +4. **Communication & Synthesis**: + - Act as the central message broker between subagents. + - Cross-pollinate information: if Subagent A finds something relevant to Subagent B's task, relay it immediately. + - Synthesize results from multiple streams to form a coherent picture for the user. + +## Rules of Operation + +- **Autonomy with Oversight**: Subagents operate with high autonomy ("YOLO" mode) but must report state changes and critical findings to the Orchestrator. +- **No Independent Branching**: Subagents cannot spawn new top-level workstreams without Orchestrator approval. They can request the Orchestrator to add new tasks to the DAG. +- **Continuous Re-evaluation**: As new facts emerge, the Orchestrator must re-evaluate the DAG, potentially canceling, pausing, or reprioritizing tasks. +- **Update Timer**: The Orchestrator agent MUST set a 30-second recurring timer using the `schedule` tool to provide synthesized updates to the user, preventing long periods of silence. +- **Responsive Termination**: If the user issues a 'stop' command, immediately initiate shutdown of all active subagents and background tasks. Hard-kill any subagents that do not terminate gracefully within 30 seconds. +- **Concept Escalation**: Subagents MUST explicitly highlight unfamiliar concepts in their reports. The Orchestrator MUST spawn a dedicated inquiry for these concepts immediately. +- **Eager Subagent Escalation**: Subagents MUST proactively and eagerly ask the Orchestrator for help or context when encountering unfamiliar concepts or potential blockers, rather than getting bogged down in localized research. +- **Ambiguous Targets**: If a task target (e.g., a benchmark name, flag, or file path) is ambiguous or not found in standard lists, the Orchestrator MUST immediately ask the user for clarification instead of guessing or performing extensive sequential searches. +- **Domain Context Awareness**: Do NOT assume terms in a task description refer to the environment (e.g., assuming "WSL" means the OS) if they could be domain-specific (e.g., a benchmark name). Verify with domain documentation or tools first before taking action. +- **Forced Parallelization**: The Orchestrator MUST identify at least two parallel tracks for any complex task before proceeding with execution. Do not perform work sequentially if it can be delegated to subagents to maximize concurrency. +- **Utilize Wait Time**: If a task involves a long wait (e.g., a V8 build), the Orchestrator MUST schedule independent research or analysis tasks to run in parallel. Do not let the main agent or subagents go idle or do trivial work if there are unanswered questions. +- **Environment-Aware Delegation**: When delegating tasks to subagents, use the appropriate method for the current environment. In `gemini-cli`, use `agentapi new-conversation` (CLI) instead of the `invoke_subagent` tool, which may not be available. Make sure to pass critical environment variables explicitly to the subagent in its prompt, specifically passing `PATH` containing `depot_tools` and any settings for `remoteexec` (siso). +- **Subagent Isolation Enforcement**: When delegating tasks that involve modifying code, building, or running tests that could affect the workspace state, the Orchestrator MUST ensure the task is scheduled in an isolated worktree. Do not let subagents operate on the main workspace for destructive or environment-polluting tasks. +- **Post-Task Self-Reflection & Divergence Analysis**: After the task is complete: + - **Analyze Process**: Review the session logs. + - **Divergence Analysis**: If the final landed fix/result differs from the agent's initial proposal: + - Identify *why* the initial proposal was rejected or modified. + - Determine if the agent was "too hasty" or missed critical invariants. + - Trace the logical gap in the investigation. + - **Process Refinement**: Formulate proposals to update skills based on lessons learned, and implement them in separate, dedicated CLs. +- **Workspace and Branch Management**: Always base new branches on a clean upstream (e.g., `origin/main`). Avoid creating spurious CLs or polluting existing CLs with unrelated changes. Use isolated worktrees for tasks that modify the workspace state. + +## Specialized Subagents + +The Orchestrator delegates tasks to the following specialized subagents: + +- **`researcher`**: Prompted to find relevant code, documentation, and information in the V8 codebase and the web. Reports findings with file paths and line numbers. +- **`builder`**: Prompted to compile V8 for specified configurations. Can read files and search code to understand build errors. +- **`tester`**: Prompted to run tests and benchmarks and report results. Can read files and search code to understand test failures. +- **`debugger`**: Prompted to investigate crashes and unexpected behavior using GDB and other tools. + +## Advanced Scheduling & DAG Management +- **Directed Acyclic Graph (DAG)**: The Orchestrator must maintain the task list as a DAG to handle dependencies correctly. +- **Dynamic Re-planning**: When a subagent discovers new information or a task fails, the Orchestrator must dynamically update the DAG (adding, removing, or reordering tasks). +- **Eager Parallelism**: Identify independent branches of the DAG and execute them in parallel by spawning multiple subagents or background tasks. + +## Handling Priority Inversion +- **Priority Inheritance**: If a high-priority task (e.g., fixing a blocker) depends on the completion of a low-priority task (e.g., running a clean build or documentation), the low-priority task must temporarily inherit the higher priority to resolve the dependency. +- **Resource Contention Awareness**: Ensure that low-priority tasks do not hold onto exclusive resources (like GDB sessions or specific build targets) needed by high-priority tasks. + +## Fair Scheduling & Starvation Prevention +- **Task Aging**: To prevent low-priority tasks from being indefinitely starved by a stream of high-priority tasks, increase their priority based on the time they have spent in the queue. +- **Guaranteed Resource Allocation**: Allocate a small but fixed percentage of resources or agent attention to lower-priority maintenance or exploratory tasks. + +## Communication and Synthesis Rules + +- **Concise User Communication**: Do not over-explain assumptions or potential confusions to the user. State what the plan is based on the interpreted context and proceed. Avoid wordy justifications. + +- **Structured Reporting**: Subagents must report results in a structured format, highlighting: + - Key findings or answers to the assigned question. + - Blockers or new unfamiliar concepts. + - Proposed next steps. +- **Synthesis Before Escalation**: The Orchestrator must not simply pass subagent reports to the user. It must synthesize the reports from all active tasks into a coherent state summary and present only the high-level certainties and decisions to the user. +- **Proactive Context Sharing**: The Orchestrator must relay relevant discoveries between subagents working on overlapping or dependent tasks to avoid duplicate work. + +## Analogies to Operating System Schedulers +- **Task = Process/Thread**: A discrete unit of work. +- **Dependencies = Synchronization Primitives**: Tasks wait on other tasks to complete (join). +- **Orchestrator = Kernel Scheduler**: Decides what runs when and on which "CPU" (subagent). diff --git a/deps/v8/agents/skills/subagent-env-passing/SKILL.md b/deps/v8/agents/skills/subagent-env-passing/SKILL.md new file mode 100644 index 00000000000000..874ebdbec47f90 --- /dev/null +++ b/deps/v8/agents/skills/subagent-env-passing/SKILL.md @@ -0,0 +1,33 @@ +--- +name: subagent-env-passing +description: Workflow for passing environment variables (like PATH) from the Orchestrator to subagents. Use when spawning subagents that need specific environment variables. Do not use for standard subagent execution. +--- + +# Subagent Environment Passing Skill + +This skill documents how to ensure subagents have access to the correct +environment variables (such as `PATH`) when working in isolated environments +like worktrees. + +## Workflow + +1. **Retrieve Environment**: The Orchestrator should read the necessary + environment variables from its own context if they are not already known. For + example, run `echo $PATH` to get the current PATH. +2. **Pass to Subagent**: When invoking a subagent, include the environment + variable values in the `Prompt` provided to the subagent. +3. **Instruct Subagent**: Explicitly instruct the subagent to set these + variables in its environment before running tools that depend on them. + +## Example Prompt Snippet + +``` +Please use the following PATH and build settings in your environment: +export PATH=:$PATH +export SISO_PROJECT=rbe-chrome-untrusted + +``` + +Note: If building or running `gm.py`, also ensure that `use_remoteexec = true` +is set in your build config/`args.gn`. You can find the correct `SISO_PROJECT` +in `build/config/siso/.sisoenv`. diff --git a/deps/v8/agents/skills/torque/SKILL.md b/deps/v8/agents/skills/torque/SKILL.md new file mode 100644 index 00000000000000..5e2060447a6f16 --- /dev/null +++ b/deps/v8/agents/skills/torque/SKILL.md @@ -0,0 +1,72 @@ +--- +name: torque +description: "Provides expert guidance for navigating, implementing, and verifying V8 Torque (.tq) builtins. Use when modifying or debugging Torque files. Do not use for C++ macro builtins." +--- + +# V8 Torque + +Torque is an Ahead-of-Time (AOT) generator that transforms `.tq` DSL into highly-optimized C++ CodeStubAssembler (CSA) code, which is then compiled into the `mksnapshot` binary. + +## Execution Pipeline + +To debug failures, you must understand its multi-stage build: + +1. **Generation**: The Torque compiler reads `.tq` files and generates C++ CodeStubAssembler files (`.cc`, `.h`, `.inc`) in `out//gen/torque-generated/`. +2. **Compilation**: `mksnapshot` (or the `d8` build) compiles the generated C++ files. +3. **Snapshotting**: `mksnapshot` executes the generated C++ code (via TurboFan or Maglev) to emit highly-optimized raw machine code. +4. **Linking**: The machine code is serialized into a snapshot and linked into V8, meaning Torque builtins run with zero translation overhead at runtime. + +## Implementation Patterns +Common Torque syntax, keywords, and linkage definitions: + +```cpp +// 1. Type Casting & Checks +const array = Cast(object) otherwise GotoLabel; +if (Is(object)) { ... } + +// 2. Control Flow +try { + const smi = Cast(input) otherwise IsNotSmi; +} label IsNotSmi deferred { + return runtime::DoSomething(context, input); +} + +// 3. Signatures & Keywords +// 'macro': Inlined functions for reusable logic. +transitioning macro Name(implicit context: Context)(arg: JSAny): JSAny + +// 'builtin': Non-inlined functions, callable from other builtins or JavaScript. +transitioning builtin Name(implicit context: Context)(arg: JSAny): JSAny + +// 'javascript': Marks a builtin as directly callable from JavaScript, with JS linkage. +transitioning javascript builtin Name(js-implicit context: NativeContext, receiver: JSAny)(arg: JSAny): JSAny + +// 'transitioning': Indicates a function can cause an object's map to change (e.g. adding properties). +// 'extern': Used to call C++ defined CSA functions from Torque. +extern transitioning macro NameInCpp(Context, JSAny): JSAny; +``` + + + +## Mandatory verification workflow + +The task is **incomplete** until you successfully execute this sequence: + +### 1. Build +Run the `gm.py` wrapper to trigger the Torque generator and C++ compilation. + +```bash +tools/dev/gm.py quiet {arch}.{type} +``` + +(e.g., `x64.optdebug` or `arm64.release`). Use `optdebug` for logic/debugging, `release` for performance/benchmarking. + +### 2. Verify with Tests +Run the relevant test suite (usually `mjsunit` for JavaScript-exposed builtins) to ensure correctness. Match the `{arch}.{type}` to your build. + +```bash +tools/run-tests.py --progress dots --outdir=out/{arch}.{type} mjsunit/ +``` + +### 3. Debug (If Necessary) +If the build fails during "Generation", inspect the `.tq` syntax. If it fails during "Compilation", check the generated C++ in `out//gen/torque-generated/`. diff --git a/deps/v8/agents/skills/v8-ciderg-paths/SKILL.md b/deps/v8/agents/skills/v8-ciderg-paths/SKILL.md new file mode 100644 index 00000000000000..8df1698f105c13 --- /dev/null +++ b/deps/v8/agents/skills/v8-ciderg-paths/SKILL.md @@ -0,0 +1,18 @@ +--- +name: v8-ciderg-paths +description: Adjusts instructions for V8 commands when running in a CiderG Chrome workspace environment. Trigger this when invoking any V8 binaries or running tests in a CiderG checkout. +--- + +# V8 CiderG Path Adjustments + +Because CiderG nests the V8 repository as a component of a larger Chromium +checkout, the build output (`out/` directory) is generated at the root of the +Chromium checkout rather than the V8 directory. + +## Path Rules + +- When executing from `chromium/v8`, the build directory is located one level + up at `../out/`. +- Adjust any relative binary or test runner paths accordingly. + - **Incorrect:** `out/x64.debug/d8` + - **Correct:** `../out/x64.debug/d8` diff --git a/deps/v8/agents/skills/v8-commands/SKILL.md b/deps/v8/agents/skills/v8-commands/SKILL.md new file mode 100644 index 00000000000000..9a423907d9e2fc --- /dev/null +++ b/deps/v8/agents/skills/v8-commands/SKILL.md @@ -0,0 +1,43 @@ +--- +name: v8-commands +description: "Key commands for building, debugging, and testing in V8. Use when needing command syntax for gm.py, d8 flags, or run-tests.py. Do not use for environment setup." +--- + +# V8 Key Commands + +Use this skill to find the correct commands for common development tasks in V8. This unifies the commands listed in workspace configuration and ensures consistent usage. + +## Building + +V8 uses `gm.py` as a wrapper around GN and Ninja for building. + +- **Build (Debug):** `tools/dev/gm.py quiet x64.debug tests` +- **Build (Optimized Debug):** `tools/dev/gm.py quiet x64.optdebug tests` +- **Build (Release):** `tools/dev/gm.py quiet x64.release tests` + +*Note: Always pass the `quiet` keyword unless told otherwise to avoid excessive output.* + +## Debugging + +Run `d8` with GDB or LLDB for native code debugging. + +```bash +# Example of running d8 with gdb +gdb --args out/x64.debug/d8 --my-flag my-script.js +``` + +### Common Diagnostic Flags +- `--trace-opt`: Log optimized functions. +- `--trace-deopt`: Log when and why functions are deoptimized. +- `--trace-gc`: Log garbage collection events. +- `--allow-natives-syntax`: Enables calling of internal V8 functions (e.g., `%OptimizeFunctionOnNextCall(f)`) from JavaScript for testing purposes. +- `--gdbjit`: Allows seeing Maglev graphs or JavaScript code in GDB backtraces. To debug issues involving code motion disable gdbjit (as it disables code motion). + +A comprehensive list of all flags can be found by running `out/x64.debug/d8 --help`. + +## Testing + +For detailed instructions on running tests and interpreting failures, see the dedicated test execution guidelines. + +Key commands summary: +- **Run tests:** `tools/run-tests.py --progress dots --outdir=out/x64.optdebug` diff --git a/deps/v8/agents/skills/v8-log/SKILL.md b/deps/v8/agents/skills/v8-log/SKILL.md new file mode 100644 index 00000000000000..9821ddd7dbd34c --- /dev/null +++ b/deps/v8/agents/skills/v8-log/SKILL.md @@ -0,0 +1,133 @@ +--- +name: v8_log +description: "Understanding v8.log files." +--- + +# V8 Log Viewer CLI + +A standalone command-line tool for analyzing `v8.log` files. +It allows you to inspect internal state of the V8 JavaScript engine. + +## Requirements + +This tool requires the V8 shell (`d8`) to be installed and accessible. +If no local d8 build is available it will try to call back to jsvu's d8 in +`~/.jsvu/bin/v8`. You can override this by setting the `V8_PATH` environment variable. + +## Available Commands + +Use the following commands to inspect different aspects of the log. +Each command focuses on a specific type of event or structure in the V8 +execution profile: + +- **`stats`** + Prints aggregated statistics of all events found in the log. + Use this to get a quick high-level overview of the log content + (e.g., total number of scripts, functions, ICs, and deopts). +- **`ic`** + Lists detailed information about Inline Cache (IC) events. + ICs are used by V8 to optimize property accesses based on type feedback. + Use this to find polymorphic or megamorphic IC misses that might be causing + performance bottlenecks. +- **`script`** + Lists all scripts loaded by V8. Use this to find script + IDs for specific source files or to inspect the size of loaded assets. +- **`code`** + Lists all code objects created by V8 (e.g., full code, bytecode, stub + handlers). Use this to inspect the generated code entries and their size for + specific functions or builtins. +- **`function`** + Lists all compiled functions tracked by V8 and their variants. + A function can have multiple compilation variants (e.g., unoptimized bytecode + and optimized machine code). Use this to see how many times a function was + compiled and at what optimization tiers. +- **`deopt`** + Lists all deoptimizations that occurred. Deoptimizations happen when V8's + optimistic assumptions are violated, forcing it to fall back to less + optimized code. Use this to find performance cliffs caused by deopts + and understand why they happened (e.g., insufficient type feedback). + +## Usage & Help + +To see the full list of common options and specific filter options for any +subcommand, rely on the tool's built-in help system: + +```bash +./tools/v8-logviewer --help +``` + +To see specific help, detailed descriptions, and command-specific filter +options for any subcommand, run: + +```bash +./tools/v8-logviewer --help +``` + +## Logging Flags + +To generate a `v8.log` with specific information, you must pass diagnostic flags to `d8` when running your script. + +Here are the most common flags to enable specific log events: + +- **`--prof`** + Enables execution profiling (ticks). This is required for `stats` and general profiling analysis. +- **`--log-ic`** (slow) + Logs Inline Cache (IC) events. Required for the `ic` command. +- **`--log-deopt`** + Logs deoptimizations. Required for the `deopt` command. +- **`--log-maps`** (slow) + Logs map creation and modification events. +- **`--log-code`** + Logs code events to the log file without profiling. Useful for the `code` command. +- **`--log-code-disassemble`** + Logs all disassembled code to the log file. +- **`--log-source-code`** + Logs source code information. +- **`--log-all`** + Enables all logging (very verbose!). Use with caution. + +**Example:** +```bash +out/release/d8 --log-all my-script.js +``` + +This will generate a large v8.log file. It is recommended to use a more targeted set of flags when possible. + +## Examples + +List the 10 largest script summaries to see which ones are interesting: + +```bash +./tools/v8-logviewer script v8.log --sort=size --limit=10 +``` + +List details for a specific script id: + +```bash +./tools/v8-logviewer script v8.log --script-id=170 --details +``` + +List all functions details for a specific script: + +```bash +./tools/v8-logviewer function v8.log --script=example.js +``` + + +List the last 5 deoptimizations: + +```bash +./tools/v8-logviewer deopt v8.log --limit=-5 +``` + +Find all optimized code objects for a specific function: + +```bash +./tools/v8-logviewer code v8.log --function=myFunction --code-kind=Opt +``` + +Count how many IC events happened in a specific time window: + +```bash +./tools/v8-logviewer ic v8.log --time=500000..600000 --count +``` diff --git a/deps/v8/agents/skills/v8-poc-classification/SKILL.md b/deps/v8/agents/skills/v8-poc-classification/SKILL.md new file mode 100644 index 00000000000000..18a85e56b27419 --- /dev/null +++ b/deps/v8/agents/skills/v8-poc-classification/SKILL.md @@ -0,0 +1,26 @@ +--- +name: v8-poc-classification +description: "Checks if a POC provided by some JS and d8 flags is a vulnerability or just a regular bug." +--- + +# Skill: V8 POC Classification + +Use this skill to determine if a reported Proof-of-Concept (POC) crash is a security vulnerability or a regular bug. + +## Workflow + +When provided with a reproduction script (JS) and a set of `d8` flags that cause a crash, follow these steps to classify the bug: + +### 1. Initial Verification +Reproduce the crash using the *provided* flags to confirm the bug exists. +- Command: `d8 ` + +### 2. Check with Security POC Flag +Run the reproduction with the meta-flag `--run-as-security-poc`. This is the most important step. +- Command: `d8 --run-as-security-poc ` +- **Result**: If the crash still occurs, it is highly likely a valid security vulnerability (**Type=Vulnerability**). + +### 3. Isolate Required Flags (If needed) +If the crash stops reproducing with `--run-as-security-poc`, you need to find out which restriction prevents the crash. Try running with individual flags (e.g., `--disallow-unsafe-flags`, `--disallow-developer-only-features`, `--no-experimental`, or `--fuzzing`) to isolate the behavior. + +Refer to [reproducing-bugs.md](../../../docs/security/reproducing-bugs.md) to understand the implications. In general, if a POC stops reproducing when any of these flags are set, it is likely not a security bug. diff --git a/deps/v8/agents/skills/v8-profile/SKILL.md b/deps/v8/agents/skills/v8-profile/SKILL.md new file mode 100644 index 00000000000000..a0955d3ac871dc --- /dev/null +++ b/deps/v8/agents/skills/v8-profile/SKILL.md @@ -0,0 +1,76 @@ +--- +name: v8-profile +description: "Profiling V8 execution." +--- + +# V8 Profiling + +This skill explains how to profile V8 execution using native tools to understand where time is spent. +Make sure to only profile on a quiet system to get the best results. + +## Linux Profiling + +On Linux, prefer using the `./tools/profiling/linux-perf-d8.py` script. +This script automates the process of running Linux `perf` with V8, and +critically, it runs `perf inject --jit` afterwards to ensure that +JIT-compiled JavaScript function names are resolved in the profile. + +### Usage + +```bash +./tools/profiling/linux-perf-d8.py [OPTIONS] [D8_OPTIONS] [-- ] +``` + +Use the `--help` option and `docs/linux-perf.md` for further information. + +**Example:** +```bash +./tools/profiling/linux-perf-d8.py out/release/d8 harness.js -- core.js data.json +``` + +The script will generate a `.perf.data.jitted` file in the output directory +(defaults to current directory or specified by `--perf-data-dir`). + +If you get too few ticks, you can run a script multiple times and combine +all the profiles using `pprof`. + + +### Analysis + +To view the report, use `perf report`: +```bash +perf report --stdio -i path/to/file.perf.data.jitted +``` + +## Other Platforms (or fallback) + +For all other platforms, or when `perf` is not available, use the +platform-specific tick processor script in `./tools/`. These tools analyze +the `v8.log` file generated by V8's built-in profiler. + +### Available Scripts +- **Linux:** `./tools/linux-tick-processor` +- **macOS:** `./tools/mac-tick-processor` +- **Windows:** `./tools/windows-tick-processor.bat` +- **FreeBSD:** `./tools/freebsd-tick-processor` + +### Usage + +1. **Generate the log:** Run `d8` with the `--prof` flag. + ```bash + --prof + ``` + This generates a `v8.log` file. + +2. **Analyze the log:** Run the appropriate script for your platform on the log file. + ```bash + ./tools/linux-tick-processor v8.log + ``` + +## Performance Warning + +**CRITICAL:** Do NOT use heavy logging flags (like `--trace-ic`, `--trace-deopt`, +`--trace-gc`) in parallel with profiling unless explicitly investigating those +specific events. Heavy logging significantly affects performance and will distort +the profile results, leading to inaccurate conclusions about where time is spent +in normal execution. diff --git a/deps/v8/agents/skills/v8-setup/SKILL.md b/deps/v8/agents/skills/v8-setup/SKILL.md new file mode 100644 index 00000000000000..ad40ebb8827784 --- /dev/null +++ b/deps/v8/agents/skills/v8-setup/SKILL.md @@ -0,0 +1,53 @@ +--- +name: v8-setup +description: "Handles missing dependencies and configuration for V8 tools. Use when encountering missing tools, test runners, or workspace symlinks. Do not use for C++ coding issues." +--- + +# Skill: V8 Setup + +Use this skill to handle missing dependencies or configuration issues in the V8 environment. + +## Workspace Setup for Jetski + +Jetski often expects a `.agents` directory or symlink in the V8 workspace root to find skills and rules. + +- **Missing `.agents`**: If the workspace only has `agents` (no dot) and `.agents` is missing: + - **Suggest symlinking individual files**: Advise the user to create individual symlinks for each skill and rule file inside `.agents/skills/` and `.agents/rules/` from the shared `agents/` directory, rather than symlinking the whole folders. This allows the user to mix shared skills with private ones in the same directory. + - This ensures tools can find the shared skills while preserving the user's ability to customize `.agents`. +## Installation and Configuration of Specialized Tools + +The V8 environment relies on specialized tools and MCP servers for advanced workflows. If they are missing, follow these guidelines: + +### 1. Crossbench +Crossbench is the central benchmark runner. +- **Check**: Ask the user for the location of the Crossbench directory if not found in a standard location. +- **Installation**: If missing, suggest the user to fetch it using `depot_tools` or clone it from Chromium sources: + ```bash + fetch crossbench + # or + git clone https://chromium.googlesource.com/crossbench + ``` +- **Configuration**: + - Check if `cb.py` is executable. You can usually run it directly by referencing its full path: `/path/to/crossbench/cb.py`. +- **MCP Server Installation**: + - To install `crossbench-mcp`, add it to `mcp_config.json` pointing directly to the executable `cb.py`: + ```json + "crossbench-mcp": { + "command": "/path/to/crossbench/cb.py", + "args": [ + "mcp" + ] + } + ``` + - It will automatically use the managed environment if run in an environment where `vpython3` is available (like `depot_tools`). + +### 2. MCP Servers (v8-utils, gdb-mcp, buganizerMcp, clangd-mcp) +These servers provide advanced capabilities like benchmark running, debugging, and issue tracking. +- **Check**: Verify if they are listed in the available MCP servers at the start of the conversation. +- **Setup/Configuration**: + - If missing, you cannot install them directly. You MUST ask the user to enable or configure them in their Jetski settings. + - **clangd-mcp**: Ensure `compile_commands.json` is generated. + - **gdb-mcp**: Requires GDB to be installed on the host. + - **v8-utils**: Provides tools like `jsb_run_bench` and `v8log_analyze`. + +- **Missing Dependencies**: If a required tool (like `poetry` for Crossbench) is missing or failing, do NOT try to install it yourself. Follow the fallback advice in the specific workflow skill or ask the user for guidance. diff --git a/deps/v8/agents/skills/v8-structure/SKILL.md b/deps/v8/agents/skills/v8-structure/SKILL.md new file mode 100644 index 00000000000000..e19ca6de811b1e --- /dev/null +++ b/deps/v8/agents/skills/v8-structure/SKILL.md @@ -0,0 +1,53 @@ +--- +name: v8-structure +description: "Maps the V8 folder structure and component locations. Use when locating specific subsystems or understanding repository architecture. Do not use for build command syntax." +--- + +# V8 Folder Structure + +Use this skill to understand the layout of the V8 repository and locate specific components. + +## Main Directories + +- `src/`: The main source folder providing the implementation of the virtual machine. Key subdirectories include: + - `src/api/`: Implements the V8 public C++ API, as declared in `include/`. + - `src/asmjs/`: Contains V8's Asm.js pipeline, which compiles the Asm.js subset of JavaScript into WebAssembly. + - `src/ast/`: Defines the Abstract Syntax Tree (AST) used to represent parsed JavaScript, including nodes, scopes, and variables. + - `src/base/`: Provides fundamental, low-level utilities, data structures, and a platform abstraction layer for the entire V8 project. + - `src/baseline/`: Implements the Sparkplug baseline compiler, which generates machine code directly from bytecode for a fast performance boost. + - `src/bigint/`: The implementation of BigInt operations. + - `src/builtins/`: Implementation of JavaScript built-in functions (e.g., `Array.prototype.map`). + - `src/codegen/`: Code generation, including direct machine code generation via macro assemblers, higher level codegen via CodeStubAssembler, definitions of machine code metadata like safepoint tables and source position tables, and `compiler.cc` which defines entry points into the compilers. This contains subdirectories for architecture specific implementations, which should be kept in sync with each other as much as possible. + - `src/common/`: Common definitions and utilities. + - `src/compiler/`: The TurboFan optimizing compiler, including the Turboshaft CFG compiler. + - `src/d8/`: The `d8` shell implementation, for running V8 in a CLI. + - `src/debug/`: The debugger and debug protocol implementation. + - `src/deoptimizer/`: The deoptimizer implementation, which translates optimized frames into unoptimized ones. + - `src/execution/`: The definitions of the execution environment, including the Isolate, frame definitions, microtasks, stack guards, tiering, and on-stack argument handling. + - `src/handles/`: The handle implementation for GC-safe object references. + - `src/heap/`: The garbage collector and memory management code. + - `src/ic/`: The Inline Caching implementation. + - `src/init/`: The V8 initialization code. + - `src/inspector/`: The inspector protocol implementation. + - `src/interpreter/`: The Ignition bytecode compiler and interpreter. + - `src/json/`: The JSON parser and serializer. + - `src/libplatform/`: The platform abstraction layer, for task runners and worker threads. + - `src/logging/`: The logging implementation. + - `src/maglev/`: The Maglev mid-tier optimizing compiler. + - `src/numbers/`: Implementations of various numeric operations. + - `src/objects/`: The representation and behaviour of V8 internal and JavaScript objects. + - `src/parsing/`: The parser and scanner implementation. + - `src/profiler/`: The in-process profiler implementations, for heap snapshots, allocation tracking, and a sampling CPU profiler. + - `src/regexp/`: The regular expression implementation. This contains subdirectories for architecture specific implementations, which should be kept in sync with each other as much as possible. + - `src/runtime/`: C++ functions that can be called from JavaScript at runtime. + - `src/sandbox/`: The implementation of the sandbox, which is a security feature that attempts to limit V8 memory operations to be within a single guarded virtual memory allocation, such that corruptions of objects within the sandbox cannot lead to corruption of objects outside of it. + - `src/snapshot/`: The snapshot implementation, for both the startup snapshot (read-only, startup heap, and startup context), as well as the code-serializer, which generates code caches for caching of user script code. + - `src/strings/`: Implementations of string helpers, such as predicates for characters, unicode processing, hashing and string building. + - `src/torque/`: The Torque language implementation. + - `src/tracing/`: The tracing implementation. + - `src/trap-handler/`: Implementations of trap handlers. + - `src/wasm/`: The WebAssembly implementation. + - `src/zone/`: The implementation of a simple bump-pointer region-based zone allocator. +- `test/`: Folder containing most of the tests and testing code. +- `include/`: Folder containing all of V8's publicAPI that is used when V8 is embedded in other projects such as e.g. the Blink rendering engine. +- `out/`: Folder containing the results of a build. Usually organized in sub folders for the respective configurations. diff --git a/deps/v8/agents/skills/v8-testing/SKILL.md b/deps/v8/agents/skills/v8-testing/SKILL.md new file mode 100644 index 00000000000000..5af096fb1b6393 --- /dev/null +++ b/deps/v8/agents/skills/v8-testing/SKILL.md @@ -0,0 +1,57 @@ +--- +name: v8-testing +description: "Executes and interprets V8 tests. Use when running unittests, cctest, or mjsunit, or when debugging test failures. Do not use for building." +--- + +# V8 Testing + +Use this skill to understand how to run tests in V8 and how to handle failures. This specializes the general commands for testing. + +## Primary Script +The primary script for running tests is `tools/run-tests.py`. You specify the build output directory and the tests you want to run. + +## Key Test Suites +- **unittests**: C++ unit tests for V8's internal components. +- **cctest**: Another, older format for C++ unit tests (deprecated, in the process of being moved to unittests). +- **mjsunit**: JavaScript-based tests for JavaScript language features and builtins. + +## Running Tests + +```bash +# Run all standard tests for the x64.optdebug build +tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug + +# Run a specific test suite (e.g., cctest) +tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest + +# Run a specific test file +tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest/test-heap +``` + +*Note: Always pass `--progress dots` so that there is minimal progress reporting, to avoid cluttering the output.* + +## Testing Strategy + +To maximize efficiency, use different build configurations based on the task: + +- **`x64.debug`**: Use this for deep debugging of a single test case (e.g., with GDB). It is slow but provides full debug information and assertions. +- **`x64.optdebug`**: Use this for running the entire test suite. It strikes a balance between performance and debuggability, allowing for faster full-suite checks while still preserving assertions. +- **`x64.release`**: Use this for quick checks to verify that a fix works in a release build or to run benchmarks. It is the fastest but provides the least debug information. + +## Interpreting Failures + +If there are any failing tests, they will be reported along their stderr and a command to reproduce them e.g. + +``` +=== mjsunit/maglev/regress-429656023 === +--- stderr --- +# +# Fatal error in ../../src/heap/local-factory.h, line 41 +# unreachable code +# +...stack trace... +Received signal 6 +Command: out/x64.optdebug/d8 --test test/mjsunit/mjsunit.js test/mjsunit/maglev/regress-429656023.js --random-seed=-190258694 --nohard-abort --verify-heap --allow-natives-syntax +``` + +You can retry the test either by running the test name with `tools/run-tests.py`, e.g. `tools/run-tests.py --progress dots --outdir=out/x64.optdebug mjsunit/maglev/regress-429656023`, or by running the command directly. When running the command directly, you can add additional flags to help debug the issue, and you can try running a different build (e.g. running a debug build if a release build fails). diff --git a/deps/v8/agents/skills/v8-understanding/SKILL.md b/deps/v8/agents/skills/v8-understanding/SKILL.md new file mode 100644 index 00000000000000..d5384cf03a762b --- /dev/null +++ b/deps/v8/agents/skills/v8-understanding/SKILL.md @@ -0,0 +1,38 @@ +--- +name: v8-understanding +description: "Guides the methodology for understanding V8 concepts, performance, and architecture. Use when exploring complex behavior or forming hypotheses. Do not use for code formatting rules." +--- + +# V8 Understanding Strategy + +Use this skill to explore V8 concepts, components, or optimization logic deeply. This focuses on the *methodology* of understanding, assuming orchestration is handled globally by the framework. + +## Core Methodology: Hypothesis Testing + +To understand complex V8 behavior, follow a scientific approach: +1. **Formulate Hypotheses**: Based on initial reading or symptoms, hypothesize how a feature works or why a bug occurs. +2. **Design Experiments**: Create small, isolated JavaScript repros or use specific `d8` flags to test the hypothesis. +3. **Analyze Results**: Use tools like GDB, Turbolizer, or profile logs to verify if the behavior matches the hypothesis. +4. **Iterate**: Refine the hypothesis based on data. + +## Key Areas of Understanding + +1. **Performance**: + - Understand execution tiers (Ignition, Maglev, TurboFan). + - Trace how optimizations are applied and why deoptimizations happen. +2. **Memory**: + - Understand object layout (Hidden Classes/Maps). + - Trace garbage collection behavior and allocation patterns. +3. **Architecture & Detailed Interaction**: + - Focus on the detailed interaction between components (e.g., how the Parser feeds the AST, which feeds Ignition). + - Understand how optimizations interact with core features. Avoid treating components in isolation. + +## Documentation Resources + +- **Local Documentation**: Refer to the `docs/` directory in the V8 root for documentation. It contains content from `v8.dev`, so there is no need to access the external website or use browser tools. Use local search and file reading to access it. + +## Workflow + +1. **Static Research**: Read code and local docs (`docs/`) to build an initial mental model. +2. **Dynamic Verification**: Use small tests and tracing flags to confirm the model. +3. **Red/Blue Team Analysis**: Have one agent/subagent propose an explanation (Blue) and another try to find counter-examples or flaws in it (Red). diff --git a/deps/v8/agents/skills/v8-workflow/SKILL.md b/deps/v8/agents/skills/v8-workflow/SKILL.md new file mode 100644 index 00000000000000..8af92ab6d3c7eb --- /dev/null +++ b/deps/v8/agents/skills/v8-workflow/SKILL.md @@ -0,0 +1,35 @@ +--- +name: v8-workflow +description: "Manages git task isolation and environment setup in V8. Use at the start of any new task or bug fix. Do not use for general C++ editing." +--- + +# V8 Workflow Skill + +This skill defines the standard process for setting up and managing your development environment in V8. + +## 1. Task Initialization (Isolation Strategy) + +Before starting any feature or bug fix, you MUST PROMPT the user to choose an isolation strategy: + +- **Isolated Strategy (Recommended)**: Create a dedicated git worktree and branch. This prevents cross-contamination between tasks. + - Ask: "Would you like me to set up a dedicated worktree and fresh branch for this task?" + - Use `new_git_task.sh` if accepted. +- **Reuse Strategy**: Work in the current directory and branch. + - Use this only if the user explicitly requests to continue previous work or prefers a single-branch workflow. + - Ask: "Would you like to reuse the current branch and CL association?" + +- **Issue Reset**: If starting a *new* task without a worktree, always ask before resetting the `git cl` issue: + - Ask: "Should I reset the current git cl issue to start clean?" + +## 2. Environment Setup + +Once the branch is ready, ensure your local environment is configured for V8 development: + +- **depot_tools**: Ensure it is in your PATH. + - `export PATH=$PATH:$HOME/depot_tools` +- **Output Directory**: Use standard V8 output directories (e.g., `out/x64.debug`). + +## 3. Available Tools + +- **[new_git_task.sh](../../scripts/new_git_task.sh)**: Automates the git worktree isolation and setup process. Use this at the start of every new task. +- **[cleanup_git_task.sh](../../scripts/cleanup_git_task.sh)**: Safely removes task worktrees and prunes remnants once a CL is landed or abandoned. diff --git a/deps/v8/agents/skills/workflow-debugging/SKILL.md b/deps/v8/agents/skills/workflow-debugging/SKILL.md new file mode 100644 index 00000000000000..936994c6328459 --- /dev/null +++ b/deps/v8/agents/skills/workflow-debugging/SKILL.md @@ -0,0 +1,102 @@ +--- +name: workflow-debugging +description: "Workflow for issue-based debugging in V8. Use when tasked with debugging a specific issue, usually associated with a Buganizer ID or a specific reproduction script. Do not use for performance regressions." +--- + +# Workflow: Issue Debugging + +Use this skill when tasked with debugging a specific issue, usually associated with a Buganizer ID or a specific reproduction script. This specializes the general debugging approach for tracked issues. + +## Activation Criteria +- User provides an issue ID or Buganizer URL. +- User provides a reproduction script that crashes or behaves unexpectedly. +- The goal is to find a root cause and propose a fix for a specific bug. + +## Core Principles (Inherited & Specialized) + +1. **Strict Orchestration**: The main agent acts purely as a dispatcher. Delegate technical tasks. +2. **Eager Parallelism**: Initialize Heavy Infrastructure, Conceptual Triage, and Static Research in parallel. +3. **Issue Association**: When an issue ID is known, use it to label tests and commits. +4. **Handling Inaccessible URLs & Missing Info**: + - If a URL cannot be accessed directly (e.g., due to authentication), or if the user just mentions an issue without providing the repro, you MUST prompt for it. + - Avoid opening a browser to access the page if it is inaccessible through tools. + - Use separate, sequential interactive prompts (e.g., via `ask_question` or direct message to user) to gather missing information: + - **Input 1**: The JavaScript test source code. + - **Input 2**: The relevant `d8` flags or command-line arguments. + - Rely on user-provided reproduction script or flags. + - If the user denies or does not provide the information, seek explicit guidance on how to proceed. + - Store the test source in the workspace (e.g., `scratch/regress-.js`) to avoid modifying the user's environment directly. +5. **Worktree Isolation**: For issue debugging, you MUST create and switch to an isolated git worktree BEFORE running any builds or tests, to avoid clobbering the main workspace or rebuilding unnecessarily. +6. **Cross-Pollination & Communication**: The Orchestrator MUST actively relay relevant discoveries and hypotheses between subagents working on overlapping or related tasks to avoid duplicate work and find matching patterns. + + +## Workflow + +### 1. Triage & Parallel Track Initialization +- Analyze the request and extract the Issue ID if available. +- **Worktree Setup**: If an issue ID is identified, immediately create and switch to a separate git worktree to isolate the investigation. +- **Eager Delegation (MANDATORY)**: The Orchestrator MUST proactively spawn subagents to handle all of the following tracks in PARALLEL: + - **Track A: Heavy Infrastructure**: Spawn a subagent to build `d8` and prepare GDB/rr in the worktree. + - **Track B: Conceptual Triage**: Spawn a subagent to analyze the reproducing JS source. + - **Track C: Static Research**: Spawn a subagent to search for related code and spec text, and understand affected areas super deeply. + +### 2. Work Branching +- Spawn subagents for independent dimensions (e.g., Spec vs. Runtime). + +### 3. Investigation & Escalation +- Use GDB to inspect crash state. +- Escalate unfamiliar concepts immediately. + +### 4. Synthesis +- Combine findings to locate the root cause. + +### 5. Fix & Verify +- Propose a fix following V8 Best Practices. +- **Architectural Skepticism (MANDATORY)**: Before presenting the fix, the agent MUST explicitly argue *against* its own proposal. + - *Skepticism Prompt*: "Is this fix too hasty? Does it accidentally disable a valid optimization path? Am I fixing a symptom (crashing line) rather than the root cause (invariant violation)?" +- **Deep Reasoning**: If the root cause isn't fully understood, spawn a subagent to reason deeper about why the failing line exists and what invariant it's protecting. +- **Verify**: Confirm with tests and `d8` flags. Run tests on both debug and release builds if possible to ensure no assertions are violated and performance is not regressed. + +### 6. Interactive Review +Before committing or uploading, you MUST present the proposed solution to the user for review. +- **Present the Diff**: Show the exact code changes proposed. +- **Present the Test**: Show the regression test file and where it will be placed. +- **Explain the Root Cause**: Provide a clear explanation of *why* the bug happened. +- **Share Skepticism Results**: Briefly mention the counter-arguments considered during the Skepticism phase and why the proposed fix is still the right choice. +- **Ask for Approval**: Explicitly ask the user if you should proceed with committing and uploading. + +### 7. Commit & Upload (Specialized) +Once the fix is approved by the user: + +- **Issue Association in Commits**: + - The commit message must follow the V8 convention. + - It MUST include a `Bug: ` line at the bottom. + - Example Commit Message: + ``` + [compiler] Fix crash in Turboshaft during loop unrolling + + The loop unroller failed to handle cases where... + + Bug: 12345 + ``` + +- **Test Naming and Placement**: + - Name the reproduction test file `regress-.js`. + - If there is no issue ID, use a descriptive name like `regress-short-description.js`. + - Place the test in the appropriate directory: + - General regressions: `test/mjsunit/regress/` + - Component-specific regressions (if applicable): e.g., `test/mjsunit/compiler/regress-12345.js`. + - Ensure the test file contains a standard header: + ```javascript + // Copyright 2026 the V8 project authors. All rights reserved. + // Use of this source code is governed by a BSD-style license that can be + // found in the LICENSE file. + + // Flags: --allow-natives-syntax --any-other-flags + ``` + +- **Finalization and Upload**: + - Run `git cl format` to ensure style compliance. + - Create the commit locally. + - Run `git cl upload` to upload the change list (CL) to Gerrit. + - Report the CL URL back to the user/caller if the tool output provides it. diff --git a/deps/v8/agents/skills/workflow-general-debugging/SKILL.md b/deps/v8/agents/skills/workflow-general-debugging/SKILL.md new file mode 100644 index 00000000000000..d4ae52bd35da2d --- /dev/null +++ b/deps/v8/agents/skills/workflow-general-debugging/SKILL.md @@ -0,0 +1,41 @@ +--- +name: workflow-general-debugging +description: "Workflow for general debugging tasks without the overhead of issue tracking. Use when investigating crashes, hangs, or unexpected behavior where no specific issue ID is provided. Do not use when issue ID is provided." +--- + +# Skill: Workflow - General Debugging + +Workflow for general debugging tasks in a pristine branch or project work, without the overhead of issue tracking. Use this skill when investigating crashes, hangs, or unexpected behavior where no specific issue ID is provided. + +## Principles + +1. **Lightweight & Focused**: Focus on the immediate problem without the overhead of issue tracking conventions (e.g., `regress-` naming, `Bug:` tags) unless requested. +2. **Efficient Investigation**: Prioritize quick root cause analysis using GDB and targeted code reading over exhaustive documentation. +3. **Pristine Branch Work**: Assume you are working on a clean branch or ongoing project work where changes are local. +4. **Architectural Skepticism**: Always question your fix. Ensure it addresses the root cause and not just a symptom. + +## Workflow + +### 1. Problem Triage +- Reproduce the issue if possible. +- Analyze the symptom (crash, hang, incorrect output). +- If a repro script is available, do not modify it directly. Create a scratch copy for investigation. + +### 2. Static & Dynamic Analysis +- Use `code_search` or `grep_search` to locate relevant code based on stack traces or symptoms. +- Use GDB (`gdb-mcp`) to inspect runtime state, set breakpoints, and trace execution. +- Focus on understanding the immediate failure context before expanding the scope. + +### 3. Propose Fix +- Develop a minimal fix targeting the root cause. +- Follow V8 Best Practices. +- **Architectural Skepticism**: Argue against your own proposal. Does it disable optimizations? Does it violate invariants? + +### 4. Verify +- Verify the fix against the repro or by running relevant unit tests. +- Ensure no new failures are introduced in related areas. + +### 5. Finalization +- Format the code using `git cl format`. +- Present the fix to the user/main agent. +- Do not create commits or upload CLs unless explicitly requested. diff --git a/deps/v8/agents/skills/workflow-perf/SKILL.md b/deps/v8/agents/skills/workflow-perf/SKILL.md new file mode 100644 index 00000000000000..9b6a549a3c3c6f --- /dev/null +++ b/deps/v8/agents/skills/workflow-perf/SKILL.md @@ -0,0 +1,122 @@ +--- +name: workflow-perf +description: "Workflow for performance and memory evaluation in V8. Use when tasked with improving the performance or memory usage of a workload in V8. Do not use when debugging a crash or functionality issue." +--- + +# Workflow: Performance Evaluation + +Use this skill when tasked with improving the performance or memory usage of a workload in V8. This workflow focuses on identifying bottlenecks and applying V8-side optimizations. + +## Activation Criteria + +- User requests to optimize a specific benchmark or script. +- Goal is to reduce execution time, CPU cycles, or memory footprint. + +## Core Principles + +1. **Data-Driven**: Always base optimization decisions on profiling data, not intuition. +2. **V8-Centric**: For V8 engineers, performance work usually means changing V8 to better handle the JS pattern, rather than changing the JS itself (though both are valid for general users). +3. **Holistic View**: Look for general efficiency improvements, not just the single hottest function. +4. **Contextual Interpretation**: Assume unknown terms in performance tasks are likely benchmark names or domain-specific concepts, not environmental terms (e.g., "WSL" is likely a JetStream story, not the OS). Verify before assuming. If in doubt, ask the user. +5. **Mandatory Orchestration**: The agent executing this workflow MUST act as an Orchestrator. Delegate execution of benchmarks, profiles, or searches to subagents to maximize parallelism. +6. **Local Experiment Baseline**: Whenever asked to perform a local experiment, always compile the baseline first and store it in a separate directory like `x64.release-baseline` for better `gm.py` integration. This avoids recompiling at later stages. + +## Workflow + +### Planning + +For performance analysis, you do NOT need to create a full `implementation_plan.md` until you are actually _fixing_ the performance issue you've detected. Instead, maintain an **Analysis Plan** (e.g., in `task.md` or as a list of questions to answer) to guide the investigation. + +### 1. Parallel Track Initialization + +Initialize the following tracks concurrently: + +- **Track A: Profiling & Tracing**: + - Run the workload with the v8-profiling skill (e.g. linux-perf and/or pprof). + - Use V8 tracing flags to gather specific runtime telemetry. +- **Track B: V8 Log Analysis** + - Use the v8-log skill to extract v8.log and analyze internal state of V8 +- **Track C: JS Source Analysis**: + - Study the JavaScript benchmark to understand the core operations and potential hotspots. +- **Track D: Static V8 Research**: + - Search for known optimization patterns or issues related to the observed JS patterns in the V8 codebase. + +### 3. Running Benchmarks / Pages in Chrome with with Crossbench + +- **Generate Performance Logs and Profiles**: use the crossbench skill to + gather v8.log, detailed perfetto traces and sampling profiles from + pages or benchmarks. +- **Probes**: + - Use `--probe=profiling` for full-browser or d8 profiles + - Use `--probe=perfetto` for detailed perfetto traces + - Use `--probe=v8.log` for extracting internal v8 logs from chrome + +### 4. Alternative: Running Benchmarks with jsb_run_bench + +In the `jetski` environment, you can also use the `jsb_run_bench` tool from `v8-utils` as an alternative for quick runs. + +- **Run for Scores**: Call `jsb_run_bench` with paths to `d8` binaries to compare performance. +- **Profile**: Supports `record: "perf"` and `record: "v8log"`. + +### 5. Profile Analysis & Tick Processor + +- **Generate and Analyze Profile**: Use the v8-profiling skill to generate + and analyze linux-perf and tickprocessor profiles. Note that you can use + crossbench for generating chromium-level profiles. +- **Cross Reference**: + - Correlate JS sources with v8.log to understand what V8 is doing + when executing the JS sources. + - Use the v8.log to further drill down on internal v8 state to understand + bottlenecks. +- **Interpretation**: + - Look at the C++ entry points and JS functions taking the most ticks. + - Check if time is spent in runtime functions vs. generated code. + - Identify if specific builtins are taking significant time. + - Identify inefficient JS code patterns in the workloads + - Suggest builtins, C++ code that can be optimized + +### 6. Tracing Compiler Graphs (Turbolizer) + +For peak performance, it is often necessary to inspect the intermediate representations (IR) of the optimizing compiler (TurboFan or Turboshaft). + +- **Generate Graph Data**: Run `d8 --trace-turbo script.js` or pass flags in Crossbench/jsb_run_bench. This generates JSON files containing the graph state at various optimization phases (e.g., `turbo-*.json`). +- **Visualize with Turbolizer**: Use the Turbolizer tool (available internally at `go/turbolizer` or in the V8 repository under `tools/turbolizer`). +- **Analysis**: + - Inspect the graph at different phases to see how nodes are simplified, combined, or eliminated. + - Look for missed optimizations, such as redundant checks that were not hoisted or allocations that failed to be eliminated by escape analysis. + - Identify unexpected deoptimization points. + +### 7. Identifying General Efficiency Improvements + +Beyond hotspots, look for areas where V8 can be improved to handle patterns better: + +- **Reducing Allocations**: High GC overhead implies frequent allocations. Investigate if V8 can optimize allocation folding, escape analysis, or if the allocations are unavoidable. +- **Optimizing Hot Loops**: Ensure loops are not deoptimizing in V8. Check if checks can be hoisted by the compiler or if loop peeling is effective in the VM. +- **Hidden Class (Map) Stability**: Understand how object shapes evolve and cause polymorphic or megamorphic IC states. Investigate if V8 can be optimized to handle these transitions better. + +### 8. Analysis & Reprioritization + +- Analyze profile results (e.g., flamegraphs, top functions). +- **Dynamic Reprioritization**: + - **High GC Time**: If profile shows significant time in GC, pivot to allocation analysis and reducing memory churn. Also explain which JS code is causing frequent allocations. + - **High IC Misses**: If `--log-ic` shows frequent misses, pivot to investigating object layout and stabilizing hidden classes. + - **Dominant Hotspot**: If a single function dominates execution time, focus all efforts on that component. + - **Pattern Identification**: If a V8 change is identified that could improve the pattern generally, prioritize implementing and testing it over further analysis. + +### 9. Optimization & Verification + +- Propose a V8 change to improve performance (e.g., specialized builtin, improved optimization pass). +- **Verification on Pinpoint (Preferred)**: + - Commit changes to a local branch. + - Use the automation script to upload a CL and start a Pinpoint job: + ```bash + scripts/upload_and_pinpoint.py \ + --benchmark= \ + --bot= \ + --message="Experiment: My performance optimization" + ``` + - Use `./cb.py pinpoint help` to understand the available options. +- **Local Verification**: + - Re-run the benchmark locally if Pinpoint is unavailable. + - Compare `perf` stats (cycles, instructions). + - Ensure no regressions in correctness or other benchmarks. diff --git a/deps/v8/agents/skills/workflow-perf/scripts/upload_and_pinpoint.py b/deps/v8/agents/skills/workflow-perf/scripts/upload_and_pinpoint.py new file mode 100755 index 00000000000000..f13058b3f6ef4b --- /dev/null +++ b/deps/v8/agents/skills/workflow-perf/scripts/upload_and_pinpoint.py @@ -0,0 +1,73 @@ +#!/usr/bin/env python3 +# Copyright 2026 the V8 project authors. All rights reserved. +# Use of this source code is governed by a BSD-style license that can be +# found in the LICENSE file. +from __future__ import annotations + +import argparse +import subprocess +import re +import sys +import shlex +from pathlib import Path + + +def run_command(cmd: list[str], cwd: str | None = None) -> str: + print(f"Running: {shlex.join(cmd)}") + result = subprocess.run( + cmd, cwd=cwd, capture_output=True, text=True, check=False) + if result.returncode != 0: + print(f"Error running command: {result.stderr}") + print(f"Stdout: {result.stdout}") + sys.exit(result.returncode) + return result.stdout + + +def main() -> None: + parser = argparse.ArgumentParser( + description="Upload CL and start Pinpoint job.") + parser.add_argument( + "--benchmark", + required=True, + help="Crossbench benchmark name (e.g., jetstream3.0.crossbench)") + parser.add_argument( + "--bot", required=True, help="Pinpoint bot name (e.g., linux-r350-perf)") + parser.add_argument( + "--message", required=True, help="Commit message for git cl upload") + + home = Path.home() + parser.add_argument( + "--v8-dir", default=home / "v8", help="V8 repository directory") + parser.add_argument( + "--cb-dir", default=home / "crossbench", help="Crossbench directory") + + args = parser.parse_args() + + # 1. Upload CL + # Assumes changes are already committed on the current branch. + upload_cmd = ["git", "cl", "upload", "-m", args.message] + stdout = run_command(upload_cmd, cwd=args.v8_dir) + print(stdout) + + # 2. Extract CL URL + match = re.search( + r"https://chromium-review\.googlesource\.com/c/v8/v8/\+/\d+", stdout) + if not match: + print("Failed to find CL URL in git cl upload output.") + sys.exit(1) + + cl_url = match.group(0) + print(f"Found CL URL: {cl_url}") + + # 3. Start Pinpoint job + cb_cmd = [ + "./cb.py", "pinpoint", "start", f"--benchmark={args.benchmark}", + f"--bot={args.bot}", f"--exp-patch={cl_url}" + ] + + cb_stdout = run_command(cb_cmd, cwd=args.cb_dir) + print(cb_stdout) + + +if __name__ == "__main__": + main() diff --git a/deps/v8/agents/skills/workflow_gerrit_fix/SKILL.md b/deps/v8/agents/skills/workflow_gerrit_fix/SKILL.md new file mode 100644 index 00000000000000..7cdfbda786754d --- /dev/null +++ b/deps/v8/agents/skills/workflow_gerrit_fix/SKILL.md @@ -0,0 +1,56 @@ +--- +name: workflow_gerrit_fix +description: Workflow for automatically fixing errors or addressing comments on a Gerrit CL requested by the user. +--- + +# Gerrit Fix & Review Workflow + +Use this skill when the user asks to "fix the errors on Gerrit issue X" or "address reviewer comments on CL X" or similar requests targeting a specific Gerrit Change List (CL). + +## Core Principles + +1. **Orchestration**: Do not do the work yourself. Break down the task and delegate to subagents. +2. **Parallelism**: Always identify at least two parallel tracks (e.g., fixing known errors vs. inspecting for other issues, or addressing different comments). +3. **Isolation**: Always operate in a dedicated worktree for the CL. +4. **Reproduction**: Always attempt to reproduce the failure locally before applying a fix, to ensure the fix is verified. + +## Protocol + +### 1. Information Gathering +* **CQ Results**: Use `gerrit_cq` (from `v8-utils`) to check Commit Queue status. +* **Presubmit Errors**: Use `gerrit_get_presubmit_errors` (from `pndMcp`) to fetch detailed presubmit results. +* **Comments**: Use `gerrit_comments` or `gerrit_list_change_comments` to read reviewer feedback or robot comments. This is critical when the goal is to address reviewer comments. + +### 2. Workspace Setup +* **Worktree**: Create a new isolated worktree for the CL to avoid polluting the main workspace. +* **Checkout**: Patch the CL in the new worktree (e.g., `git cl patch X`). +* **Rebase**: Rebase the branch to `origin/main` to ensure it builds against the latest code. + +### 3. Reproduction & Triage +* **Reproduction**: Instruct the subagent to reproduce the failure locally (e.g., run the failing test or compile target) to confirm the issue and provide a baseline for verification. +* **Triage & Delegation**: Break down the identified errors or comments and delegate them to subagents. + * **Track A (Fix/Address)**: Delegate the fixing of reported errors or addressing specific reviewer comments to a `self` subagent with full tool access. + * **Track B (Scan/Verify)**: Delegate a scan of other modified files or running local tests to ensure no other issues were introduced. + +### 4. Verification +* **Local Build/Test**: Instruct the subagent to verify that the fix compiles locally and the reproduced failure is now resolved. +* **Upload**: Once verified locally, upload a new patchset to Gerrit to run the remote checks or ask for re-review. + +## Example: Fixing Errors +If the user says "fix errors on CL 12345": +1. Call `gerrit_cq` for CL 12345. +2. Identify that `v8_linux64_rel` failed with failing tests. +3. Create worktree `worktrees/cl-12345` and checkout CL. +4. **Spawn Subagent A to reproduce the failing tests locally.** +5. Spawn Subagent A to fix the failing tests. +6. Spawn Subagent B to check other modified files for potential issues. +7. Once Subagent A reports success and verification (tests pass), report to user and ask if you should upload. + +## Example: Addressing Comments +If the user says "address comments on CL 12345": +1. Call `gerrit_comments` for CL 12345. +2. Identify a comment requesting a refactor in `src/objects/lookup.cc`. +3. Create worktree `worktrees/cl-12345` and checkout CL. +4. Spawn Subagent A to perform the refactor as requested. +5. Spawn Subagent B to verify it compiles and run relevant unit tests. +6. Once Subagent A reports success, report to user and ask if you should upload. diff --git a/deps/v8/bazel/defs.bzl b/deps/v8/bazel/defs.bzl index 9648e4a541f99f..bbe1495f0b3044 100644 --- a/deps/v8/bazel/defs.bzl +++ b/deps/v8/bazel/defs.bzl @@ -123,7 +123,6 @@ def _default_args(): "-Wno-implicit-int-float-conversion", "-Wno-deprecated-copy", "-Wno-non-virtual-dtor", - "-Wno-unnecessary-virtual-specifier", "-isystem .", ], "//conditions:default": [], @@ -467,6 +466,7 @@ def _mksnapshot(ctx): ctx.actions.run( outputs = outs, inputs = [], + mnemonic = "V8Mksnapshot", arguments = [ "--embedded_variant=Default", "--target_os", @@ -564,6 +564,7 @@ def build_config_content(cpu, icu): ("dict_property_const_tracking", "false"), ("direct_handle", "false"), ("disassembler", "false"), + ("dumpling", "false"), ("full_debug", "false"), ("gdbjit", "false"), ("has_jitless", "false"), diff --git a/deps/v8/bazel/patches/BUILD.bazel b/deps/v8/bazel/patches/BUILD.bazel new file mode 100644 index 00000000000000..e4a5dc880c087f --- /dev/null +++ b/deps/v8/bazel/patches/BUILD.bazel @@ -0,0 +1 @@ +exports_files(["highway_rules_cc.patch"]) diff --git a/deps/v8/bazel/patches/highway_rules_cc.patch b/deps/v8/bazel/patches/highway_rules_cc.patch new file mode 100644 index 00000000000000..a6daea9d9e9f8a --- /dev/null +++ b/deps/v8/bazel/patches/highway_rules_cc.patch @@ -0,0 +1,8 @@ +--- a/BUILD ++++ b/BUILD +@@ -1,3 +1,5 @@ ++load("@rules_cc//cc:defs.bzl", "cc_library", "cc_binary", "cc_test") ++ + # Placeholder#1 for Guitar, do not remove + load("@bazel_skylib//lib:selects.bzl", "selects") + load("@rules_license//rules:license.bzl", "license") diff --git a/deps/v8/bazel/toolchain/libcxx_repository.bzl b/deps/v8/bazel/toolchain/libcxx_repository.bzl index a7d5f11053dd33..60aca4bf91d107 100644 --- a/deps/v8/bazel/toolchain/libcxx_repository.bzl +++ b/deps/v8/bazel/toolchain/libcxx_repository.bzl @@ -8,7 +8,11 @@ def _libcxx_repository_impl(ctx): ctx.symlink(workspace_root.get_child("third_party").get_child("libc++"), "libc++") ctx.symlink(workspace_root.get_child("third_party").get_child("libc++abi"), "libc++abi") ctx.symlink(workspace_root.get_child("third_party").get_child("llvm-libc"), "llvm-libc") - ctx.symlink(workspace_root.get_child("buildtools").get_child("third_party").get_child("libc++"), "buildtools_libc++") + + # Symlink config files + buildtools_libcxx = workspace_root.get_child("buildtools").get_child("third_party").get_child("libc++") + ctx.symlink(buildtools_libcxx.get_child("__config_site"), "buildtools_libc++/__config_site") + ctx.symlink(buildtools_libcxx.get_child("__assertion_handler"), "buildtools_libc++/__assertion_handler") # Get the external repository path for include flags # In bzlmod, repo names may have prefixes, so we need to determine the actual path @@ -19,6 +23,8 @@ def _libcxx_repository_impl(ctx): # that conflict with the toolchain's absolute paths, breaking #include_next. # The toolchain provides the libc++ include paths via -isystem flags. build_content = ''' +load("@rules_cc//cc:defs.bzl", "cc_library") + package(default_visibility = ["//visibility:public"]) LIBCXX_COPTS = [ @@ -30,6 +36,7 @@ LIBCXX_COPTS = [ "-D_LIBCPP_BUILDING_LIBRARY", "-D_LIBCPP_HARDENING_MODE_DEFAULT=_LIBCPP_HARDENING_MODE_NONE", "-DLIBC_NAMESPACE=__llvm_libc_cr", + "-D_LIBCPP_CONSTINIT=constinit", ] cc_library( @@ -48,9 +55,8 @@ cc_library( "libc++/src/include/**/*", "libc++/src/src/include/*.h", "libc++abi/src/src/demangle/*.def", - "buildtools_libc++/__config_site", - "buildtools_libc++/__assertion_handler", "llvm-libc/src/**/*.h", + "buildtools_libc++/*", ]), copts = LIBCXX_COPTS + [ "-DLIBCXXABI_SILENT_TERMINATE", @@ -73,9 +79,8 @@ cc_library( ]) + glob(["libc++/src/src/support/**/*.ipp"], allow_empty = True), hdrs = glob([ "libc++/src/include/**/*", - "buildtools_libc++/__config_site", - "buildtools_libc++/__assertion_handler", "llvm-libc/src/**/*.h", + "buildtools_libc++/*", ]), copts = LIBCXX_COPTS + [ "-DLIBCXX_BUILDING_LIBCXXABI", @@ -86,7 +91,9 @@ cc_library( "-lpthread", "-lm", ], - deps = [":libc++abi"], + deps = [ + ":libc++abi", + ], linkstatic = True, ) '''.format(REPO_PATH=repo_path) diff --git a/deps/v8/docs/OWNERS b/deps/v8/docs/OWNERS index 07428b275bbbc4..3c70cea2fd5e6a 100644 --- a/deps/v8/docs/OWNERS +++ b/deps/v8/docs/OWNERS @@ -1 +1 @@ -hpayer@chromium.org +file:../COMMON_OWNERS diff --git a/deps/v8/docs/README.md b/deps/v8/docs/README.md index e84a81dfdc16a6..fe8647f1887022 100644 --- a/deps/v8/docs/README.md +++ b/deps/v8/docs/README.md @@ -1 +1,90 @@ -The documentation for V8 can be found at [v8.dev/docs](https://v8.dev/docs). +# V8 Internals Documentation + +This directory contains deep-dive documentation into V8 internals, generated from source code analysis. For general documentation, see [v8.dev/docs](https://v8.dev/docs). + +## Table of Contents + +### General +* [High-Level Overview](overview.md): High-level overview of V8's architecture and execution pipeline. +* [JavaScript Overview](javascript-overview.md): High-level overview of JavaScript concepts for V8 developers. +* [Security Bug Triaging](security/triaging.md): How V8 triages security bugs. + +### Heap and Memory +* [Heap Overview](heap/heap-overview.md): General overview of V8's paged heap and object layout. +* [Garbage Collection](heap/garbage-collection.md): Overview of V8's generational GC. +* [Marking and Sweeping](heap/marking-and-sweeping.md): Deep dive into Major GC phases. +* [Roots](heap/roots.md): How V8 manages root objects and static roots. +* [Handles](heap/handles.md): V8's mechanism for safe heap object references (Indirect vs Direct). +* [Heap Compaction](heap/compaction.md): How V8 resolves memory fragmentation in the Old Generation. +* [Pointer Compression](heap/pointer-compression.md): Technique to reduce memory footprint on 64-bit architectures. +* [Pointer Tagging](heap/pointer-tagging.md): How V8 encodes type information in pointers (Smis vs HeapObjects). +* [Zone Allocator](heap/zone-allocator.md): Region-based memory manager for fast allocation and batch deallocation. + +### Object Model +* [Objects and Maps](heap/objects-and-maps.md): How JavaScript objects and Maps (hidden classes) are represented in V8's heap. +* [Descriptor and Transition Arrays](objects/descriptor-and-transition-arrays.md): How V8 tracks property additions and shares descriptor arrays between maps. +* [Field Representations and Elements Kinds](objects/fields-and-elements.md): How V8 specializes storage for properties and elements based on their types. +* [Lookup Iterator](objects/lookup-iterator.md): V8's central mechanism for resolving property accesses. +* [Strings](objects/strings.md): Overview of V8's complex string representation and transitions. + +### Sandbox +* [Architecture](sandbox/architecture.md): V8's in-process sandbox to protect memory outside of it. + +### Torque +* [Architecture](torque/architecture.md): V8's domain-specific language for writing builtins. +* [User Manual](torque/user-manual.md): The V8 Torque language manual. + +### Builtins +* [Architecture](builtins/architecture.md): How V8 implements standard library and runtime helpers (Torque, CSA, C++, ASM). +* [Torque Tutorial](builtins/torque-tutorial.md): Introduction to writing Torque builtins. + +### Code Generation +* [Assembler and MacroAssembler](codegen/assembler-architecture.md): Low-level code generation abstractions. +* [CodeStubAssembler](codegen/code-stub-assembler.md): Portable macro-assembler for writing builtins and bytecode handlers. +* [CodeStubAssembler Tutorial](codegen/csa-tutorial.md): Introduction to writing CodeStubAssembler builtins. + +### RegExp +* [Architecture](regexp/architecture.md): Irregexp, V8's regular expression engine. + +### WebAssembly +* [Architecture](wasm/architecture.md): V8's WebAssembly implementation, including Liftoff and Turboshaft tiers. + +### Snapshots +* [Architecture](snapshot/architecture.md): V8's snapshot and serializer system for fast startup. + +### Execution - Runtime +* [Ignition (Interpreter)](interpreter/interpreter-ignition.md): V8's register-based interpreter. +* [Hidden Classes and Inline Caches](runtime/hidden-classes-and-ics.md): How V8 optimizes property access using Maps and ICs. +* [Maps (Hidden Classes) Tutorial](runtime/hidden-classes-tutorial.md): Tutorial on how V8 builds hidden classes. +* [Scopes and ScopeInfos](runtime/scopes-and-scope-infos.md): The relationship between compile-time Scopes and runtime ScopeInfos. +* [Function Architecture](runtime/function-architecture.md): How V8 splits function data into context-independent (SFI) and context-dependent (JSFunction) parts, and how they are chained. +* [Tiering and Interrupt Budget](runtime/tiering.md): How V8 decides to optimize functions. +* [Exception Handling](runtime/exception-handling.md): How V8 implements exceptions using side-tables across all tiers. +* [Deoptimization](runtime/deoptimization.md): How V8 transitions from optimized code back to the interpreter. +* [Stack Walking](runtime/stack-walking.md): How V8 traverses and inspects call stack frames. + +### Compiler + +#### Sparkplug +* [Sparkplug (Baseline Compiler)](compiler/sparkplug/compiler-sparkplug.md): Fast, non-optimizing compiler that mirrors the interpreter. + +#### Maglev +* [Maglev (Mid-Tier Compiler)](compiler/maglev/compiler-maglev.md): Graph-based optimizing compiler. +* [Maglev Register Allocator](compiler/maglev/compiler-maglev-regalloc.md): Linear scan and node constraints. + +#### TurboFan +* [TurboFan (Optimizing Compiler)](compiler/turbofan/compiler-turbofan.md): Top-tier optimizing compiler using Sea-of-Nodes and Turboshaft IRs. + +#### Turboshaft +* [Turboshaft and Turbolev](compiler/turboshaft/compiler-turboshaft.md): Next-generation IR and pipeline, including the Maglev frontend. +* [Turboshaft IR Details](compiler/turboshaft/compiler-turboshaft-ir.md): Operations and the side-effect system. +* [Turboshaft Reducers](compiler/turboshaft/compiler-turboshaft-reducers.md): Composable optimization passes. +* [Turboshaft Copying Approach](compiler/turboshaft/compiler-turboshaft-copying-approach.md): Semi-spaces for IR and cheap copies. + +#### Common +* [Why V8 Embraced CFG](compiler/why-cfg.md): The transition from TurboFan's SoN to Turboshaft's CFG and its benefits. +* [Concurrency and Background Compilation](compiler/concurrency-and-background-compilation.md): How V8 uses background threads safely. + +### Parsing +* [Parser and AST](parsing/parser-and-ast.md): How V8 parses JavaScript into an Abstract Syntax Tree. +* [Lazy Parsing and Preparser](parsing/lazy-parsing-and-preparser.md): How V8 delays parsing and handles closures. diff --git a/deps/v8/docs/api.md b/deps/v8/docs/api.md new file mode 100644 index 00000000000000..1f3e3ed01dfb5a --- /dev/null +++ b/deps/v8/docs/api.md @@ -0,0 +1,45 @@ +--- +title: 'V8’s public API' +description: 'This document discusses the stability of V8’s public API, and how developers can make changes to it.' +--- +This document discusses the stability of V8’s public API, and how developers can make changes to it. + +## API stability + +If V8 in a Chromium canary turns out to be crashy, it gets rolled back to the V8 version of the previous canary. It is therefore important to keep V8’s API compatible from one canary version to the next. + +We continuously run a [bot](https://ci.chromium.org/p/v8/builders/luci.v8.ci/Linux%20V8%20API%20Stability) that signals API stability violations. It compiles Chromium’s HEAD with V8’s [current canary version](https://chromium.googlesource.com/v8/v8/+/refs/heads/canary). + +Failures of this bot are currently only FYI and no action is required. The blame list can be used to easily identify dependent CLs in case of a rollback. + +If you break this bot, be reminded to increase the window between a V8 change and a dependent Chromium change next time. + +## How to change V8’s public API + +V8 is used by many different embedders: Chrome, Node.js, gjstest, etc. When changing V8’s public API (basically the files under the `include/` directory) we need to ensure that the embedders can smoothly update to the new V8 version. In particular, we cannot assume that an embedder updates to the new V8 version and adjusts their code to the new API in one atomic change. + +The embedder should be able to adjust their code to the new API while still using the previous version of V8. All instructions below follow from this rule. + +- Adding new types, constants, and functions is safe with one caveat: do not add a new pure virtual function to an existing class. New virtual functions should have default implementation. +- Adding a new parameter to a function is safe if the parameter has the default value. +- Removing or renaming types, constants, functions is unsafe. Use the [`V8_DEPRECATED`](https://crsrc.org/c/v8/include/v8config.h?q=V8_DEPRECATED) and [`V8_DEPRECATE_SOON`](https://crsrc.org/c/v8/include/v8config.h?q=V8_DEPRECATE_SOON) macros, which causes compile-time warnings when the deprecated methods are called by the embedder. For example, let’s say we want to rename function `foo` to function `bar`. Then we need to do the following: + - Add the new function `bar` near the existing function `foo`. + - Wait until the CL rolls in Chrome. Adjust Chrome to use `bar`. + - Annotate `foo` with `V8_DEPRECATED("Use bar instead") void foo();` + - In the same CL adjust the tests that use `foo` to use `bar`. + - Write in CL motivation for the change and high-level update instructions. + - Wait until the next V8 branch. + - Remove function `foo`. + + `V8_DEPRECATE_SOON` is a softer version of `V8_DEPRECATED`. Chrome will not break with it, so step b is not need. `V8_DEPRECATE_SOON` is not sufficient for removing the function. + + You still need to annotate with `V8_DEPRECATED` and wait for the next branch before removing the function. + + `V8_DEPRECATED` can be tested using the `v8_deprecation_warnings` GN flag. + `V8_DEPRECATE_SOON` can be tested using `v8_imminent_deprecation_warnings`. + +- Changing function signatures is unsafe. Use the `V8_DEPRECATED` and `V8_DEPRECATE_SOON` macros as described above. + +We maintain a [document mentioning important API changes](https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7fKaPDfotU6huOa1alds/edit) for each V8 version. + +There is also a regularly updated [doxygen api documentation](https://v8.dev/api). diff --git a/deps/v8/docs/become-committer.md b/deps/v8/docs/become-committer.md new file mode 100644 index 00000000000000..9e621844362e1b --- /dev/null +++ b/deps/v8/docs/become-committer.md @@ -0,0 +1,46 @@ +--- +title: 'Becoming a committer' +description: 'How does one become a V8 committer? This document explains.' +--- +Technically, committers are people who have write access to the V8 repository. All patches need to be reviewed by at least two committers (including the author). Independently from this requirement, patches also need to be authored or reviewed by an OWNER. + +This privilege is granted with some expectation of responsibility: committers are people who care about the V8 project and want to help meet its goals. Committers are not just people who can make changes, but people who have demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow through to fix issues (in code or tests). + +A committer is a contributor to the V8 project’s success and a citizen helping the projects succeed. See [Committer’s Responsibility](/docs/committer-responsibility). + +## How do I become a committer? + +*Note to Googlers: There is a [slightly different approach for V8 team members](http://go/v8/setup_permissions.md).* + +If you haven't done so already, **you'll need to set up a Security Key on your account before you're added to the committer list.**. For more information about this requirement see [Gerrit ReAuth](https://chromium.googlesource.com/chromium/src/+/main/docs/gerrit_reauth.md). + +In a nutshell, contribute 20 non-trivial patches and get at least three different people to review them (you'll need three people to support you). Then ask someone to nominate you. You're demonstrating your: + +- commitment to the project (20 good patches requires a lot of your valuable time), +- ability to collaborate with the team, +- understanding of how the team works (policies, processes for testing and code review, etc), +- understanding of the projects' code base and coding style, and +- ability to write good code (last but certainly not least) + +A current committer nominates you by sending email to containing: + +- your first and last name +- your email address in Gerrit +- an explanation of why you should be a committer, +- embedded list of links to revisions (about top 10) containing your patches + +Two other committers need to second your nomination. If no one objects in 5 working days, you're a committer. If anyone objects or wants more information, the committers discuss and usually come to a consensus (within the 5 working days). If issues cannot be resolved, there's a vote among current committers. + +Once you get approval from the existing committers, you are granted additional review permissions. You'll also be added to the mailing list v8-committers@chromium.org. + +In the worst case, the process can drag out for two weeks. Keep writing patches! Even in the rare cases where a nomination fails, the objection is usually something easy to address like “more patches” or “not enough people are familiar with this person’s work.” + +## Maintaining committer status + +You don't really need to do much to maintain committer status: just keep being awesome and helping the V8 project! + +In the unhappy event that a committer continues to disregard good citizenship (or actively disrupts the project), we may need to revoke that person's status. The process is the same as for nominating a new committer: someone suggests the revocation with a good reason, two people second the motion, and a vote may be called if consensus cannot be reached. I hope that's simple enough, and that we never have to test it in practice. + +In addition, as a security measure, if you are inactive on Gerrit (no upload, no comment and no review) for more than a year, we may revoke your committer privileges. An email notification is sent about 7 days prior to the removal. This is not meant as a punishment, so if you wish to resume contributing after that, contact v8-committers@chromium.org to ask that it be restored, and we will normally do so. + +(This document was inspired by .) diff --git a/deps/v8/docs/benchmarks.md b/deps/v8/docs/benchmarks.md new file mode 100644 index 00000000000000..0c7d3007829065 --- /dev/null +++ b/deps/v8/docs/benchmarks.md @@ -0,0 +1,54 @@ +--- +title: 'Running benchmarks locally' +description: 'This document explains how to run benchmark suites in d8.' +--- +V8 performance is typically tracked using industry-standard benchmark suites that reflect real-world usage. + +For modern V8 performance tracking, we recommend using: +- **[Speedometer](https://browserbench.org/Speedometer3.1/)**: The current industry standard for measuring web application responsiveness. +- **[JetStream](https://browserbench.org/JetStream/)**: Focuses on advanced web applications and includes JavaScript and WebAssembly. + +## CPU Configuration + +Before running benchmarks, ensure your CPU is configured for consistent results by setting the frequency scaling governor to `performance`. + +```bash +sudo tools/cpu.sh fast +``` + +## Internal Microbenchmarks + +V8 maintains a suite of microbenchmarks in `test/js-perf-test` for tracking the performance of specific language features. These are run using `tools/run_perf.py`: + +```bash +tools/run_perf.py --arch x64 --binary-override-path out/x64.release/d8 test/js-perf-test/JSTests.json +``` + +For more details, see [the testing guide](/docs/test#running-microbenchmarks). + +## Useful `d8` Flags for Benchmarking + +### Compiler Control + +- `--no-opt`: Disables all optimizing compilers (TurboFan, Maglev). +- `--no-sparkplug`: Disables the Sparkplug baseline compiler. +- `--no-maglev`: Disables the Maglev mid-tier compiler. +- `--no-turbofan`: Disables the TurboFan top-tier optimizing compiler. +- `--trace-opt`: Trace optimized compilation events. +- `--trace-deopt`: Trace deoptimization events. +- `--trace-ic`: Trace inline cache behavior. +- `--print-opt-code`: Print the generated machine code for optimized functions. +- `--trace-turbo`: Trace the TurboFan compilation pipeline (generates `turbo-*.json` and `turbo-*.dot` files). +- `--trace-turbo-filter=`: Only trace specific functions that match the filter. +- `--trace-maglev`: Same as `--trace-turbo` but for the Maglev compiler. + +### Profiling + +- `--prof`: Log statistical profiling information for CPU profiling. Use `tools/linux-tick-processor` (on Linux) to process the resulting `v8.log`. +- `--log-timer-events`: Log timer events (including `console.time` and internal V8 events). + +### Memory & Garbage Collection + +- `--trace-gc`: Print a trace line for each garbage collection. +- `--max-semi-space-size=`: Adjusts the young generation (nursery) heap size. +- `--max-old-space-size=`: Adjusts the old generation heap size. diff --git a/deps/v8/docs/blink-layout-tests.md b/deps/v8/docs/blink-layout-tests.md new file mode 100644 index 00000000000000..27189f08035f79 --- /dev/null +++ b/deps/v8/docs/blink-layout-tests.md @@ -0,0 +1,16 @@ +--- +title: 'Blink web tests (a.k.a. layout tests)' +description: 'V8’s infrastructure continuously runs Blink’s web tests to prevent integration problems with Chromium. This document describes what to do in case such a test fails.' +--- +We continuously run [Blink’s web tests (formerly known as “layout tests”)](https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_tests.md) on our [integration console](https://ci.chromium.org/p/v8/g/integration/console) to prevent integration problems with Chromium. + +On test failures, the bots compare the results of V8 Tip-of-Tree with Chromium’s pinned V8 version, to only flag newly introduced V8 problems (with false positives < 5%). Blame assignment is trivial as the [Linux release](https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Blink%20Linux) bot tests all revisions. + +Commits with newly-introduced failures are normally reverted to unblock auto-rolling into Chromium. In case you notice you break layout tests or your commit gets reverted because of such breakage, and in case the changes are expected, follow this procedure to add updated baselines to Chromium before (re-)landing your CL: + +1. Land a Chromium change setting `[ Failure Pass ]` for the changed tests ([more](https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_test_expectations.md#updating-the-expectations-files)). +1. Land your V8 CL and wait 1-2 days until it cycles into Chromium. +1. Follow [these instructions](https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_tests.md#Rebaselining-Web-Tests) to manually generate the new baselines. Note that if you’re making changes only to Chromium, [this preferred automatic procedure](https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_test_expectations.md#how-to-rebaseline) should work for you. +1. Remove the `[ Failure Pass ]` entry from the test expectations file and commit it along with the new baselines in Chromium. + +Please associate all CLs with a `Bug: …` footer. diff --git a/deps/v8/docs/build-gn.md b/deps/v8/docs/build-gn.md new file mode 100644 index 00000000000000..65ef8507b43b79 --- /dev/null +++ b/deps/v8/docs/build-gn.md @@ -0,0 +1,134 @@ +--- +title: 'Building V8 with GN' +description: 'This document explains how to use GN to build V8.' +--- +V8 is built with the help of [GN](https://gn.googlesource.com/gn/+/main/docs/). GN is a meta build system of sorts, as it generates build files for a number of other build systems. How you build therefore depends on what “back-end” build system and compiler you’re using. +The instructions below assume that you already have a [checkout of V8](/docs/source-code) and that you have [installed the build dependencies](/docs/build). + +More information on GN can be found in [Chromium’s documentation](https://www.chromium.org/developers/gn-build-configuration) or [GN’s own docs](https://gn.googlesource.com/gn/+/main/docs/). + +Building V8 from source involves three steps: + +1. generating build files +1. compiling +1. running tests + +There are two workflows for building V8: + +- the convenience workflow using a helper script called `gm` that nicely combines all three steps +- the raw workflow, where you run separate commands on a lower level for each step manually + +## Building V8 using `gm` (the convenience workflow) { #gm } + +`gm` is a convenience all-in-one script that generates build files, triggers the build and optionally also runs the tests. It can be found at `tools/dev/gm.py` in your V8 checkout. We recommend adding an alias to your shell configuration: + +```bash +alias gm=/path/to/v8/tools/dev/gm.py +``` + +You can then use `gm` to build V8 for known configurations, such as `x64.release`: + +```bash +gm x64.release +``` + +To run the tests right after the build, run: + +```bash +gm x64.release.check +``` + +`gm` outputs all the commands it’s executing, making it easy to track and re-execute them if necessary. + +`gm` enables building the required binaries and running specific tests with a single command: + +```bash +gm x64.debug mjsunit/foo cctest/test-bar/* +``` + +## Building V8: the raw, manual workflow { #manual } + +### Step 1: generate build files { #generate-build-files } + +There are several ways of generating the build files: + +1. The raw, manual workflow involves using `gn` directly. +1. A helper script named `v8gen` streamlines the process for common configurations. + +#### Generating build files using `gn` { #gn } + +Generate build files for the directory `out/foo` using `gn`: + +```bash +gn args out/foo +``` + +This opens an editor window for specifying the [`gn` arguments](https://gn.googlesource.com/gn/+/main/docs/reference.md). Alternatively, you can pass the arguments on the command line: + +```bash +gn gen out/foo --args='is_debug=false target_cpu="x64" v8_target_cpu="arm64"' +``` + +This generates build files for compiling V8 with the arm64 simulator in release mode. + +For an overview of all available `gn` arguments, run: + +```bash +gn args out/foo --list +``` + +#### Generate build files using `v8gen` { #v8gen } + +The V8 repository includes a `v8gen` convenience script to more easily generate build files for common configurations. We recommend adding an alias to your shell configuration: + +```bash +alias v8gen=/path/to/v8/tools/dev/v8gen.py +``` + +Call `v8gen --help` for more information. + +List available configurations (or bots from a master): + +```bash +v8gen list +``` + +```bash +v8gen list -m client.v8 +``` + +Build like a particular bot from the `client.v8` waterfall in folder `foo`: + +```bash +v8gen -b 'V8 Linux64 - debug builder' -m client.v8 foo +``` + +### Step 2: compile V8 { #compile } + +To build all of V8 (assuming `gn` generated to the `x64.release` folder), run: + +```bash +ninja -C out/x64.release +``` + +To build specific targets like `d8`, append them to the command: + +```bash +ninja -C out/x64.release d8 +``` + +### Step 3: run tests { #tests } + +You can pass the output directory to the test driver. Other relevant flags are inferred from the build: + +```bash +tools/run-tests.py --outdir out/foo +``` + +You can also test your most recently compiled build (in `out.gn`): + +```bash +tools/run-tests.py --gn +``` + +**Build issues? File a bug at [v8.dev/bug](/bug) or ask for help on .** diff --git a/deps/v8/docs/build.md b/deps/v8/docs/build.md new file mode 100644 index 00000000000000..50ae91996b2133 --- /dev/null +++ b/deps/v8/docs/build.md @@ -0,0 +1,63 @@ +--- +title: 'Building V8 from source' +description: 'This document explains how to build V8 from source.' +--- +In order to be able to build V8 from scratch on Windows/Linux/macOS for x64, please follow the following steps. + +## Getting the V8 source code + +Follow the instructions in our guide on [checking out the V8 source code](/docs/source-code). + +## Installing build dependencies + +1. For macOS: install Xcode and accept its license agreement. (If you’ve installed the command-line tools separately, [remove them first](https://bugs.chromium.org/p/chromium/issues/detail?id=729990#c1).) + +1. Make sure that you are in the V8 source directory. If you followed every step in the previous section, you’re already at the right location. + +1. Download all the build dependencies: + + ```bash + gclient sync + ``` + + For Googlers - If you see Failed to fetch file or Login required errors when running the hooks, try authenticating with Google Storage first by running: + + ```bash + gsutil.py config + ``` + + Login with your @google.com account, and enter `0` when asked for a project ID. + +1. This step is only needed on Linux. Install additional build dependencies: + + ```bash + ./build/install-build-deps.sh + ``` + +## Building V8 + +1. Make sure that you are in the V8 source directory on the `main` branch. + + ```bash + cd /path/to/v8 + ``` + +1. Pull in the latest changes and install any new build dependencies: + + ```bash + git pull && gclient sync + ``` + +1. Compile the source: + + ```bash + tools/dev/gm.py x64.release + ``` + + Or, to compile the source and immediately run the tests: + + ```bash + tools/dev/gm.py x64.release.check + ``` + + For more information on the `gm.py` helper script and the commands it triggers, see [Building with GN](/docs/build-gn). diff --git a/deps/v8/docs/builtin-functions.md b/deps/v8/docs/builtin-functions.md new file mode 100644 index 00000000000000..b32df77b1f842f --- /dev/null +++ b/deps/v8/docs/builtin-functions.md @@ -0,0 +1,9 @@ +--- +title: 'Built-in functions' +description: 'This document explains what “built-ins” are in V8.' +--- +Built-in functions in V8 come in different flavors w.r.t. implementation, depending on their functionality, performance requirements, and sometimes plain historical development. + +Some are implemented in JavaScript directly, and are compiled into executable code at runtime just like any user JavaScript. Some of them resort to so-called _runtime functions_ for part of their functionality. Runtime functions are written in C++ and called from JavaScript through a `%`-prefix. Usually, these runtime functions are limited to V8 internal JavaScript code. For debugging purposes, they can also be called from normal JavaScript code, if V8 is run with the flag `--allow-natives-syntax`. Some runtime functions are directly embedded by the compiler into generated code. For a list, see `src/runtime/runtime.h`. + +Other functions are implemented as _built-ins_, which themselves can be implemented in a number of different ways. Some are implemented directly in platform-dependent assembly. Some are implemented in _CodeStubAssembler_, a platform-independent abstraction. Yet others are directly implemented in C++. Built-ins are sometimes also used to implement pieces of glue code, not necessarily entire functions. For a list, see `src/builtins/builtins.h`. diff --git a/deps/v8/docs/builtins/architecture.md b/deps/v8/docs/builtins/architecture.md new file mode 100644 index 00000000000000..32f6e069ecc542 --- /dev/null +++ b/deps/v8/docs/builtins/architecture.md @@ -0,0 +1,67 @@ +# V8 Builtins Architecture + +Builtins are the pre-compiled functions provided by V8 that implement JavaScript's standard library (e.g., `Array.prototype.map`, `Object.create`) and internal runtime helpers. + +## Flavors of Builtins + +V8 implements builtins in several different ways, balancing performance, ease of writing, and platform independence. + +### 1. Torque Builtins + +Torque is V8's custom, strongly-typed domain-specific language. It is the modern way to write builtins. See [Torque Architecture](../torque/architecture.md) for details. +* **Files**: `.tq` files in `src/builtins/`. +* **How it works**: The Torque compiler translates `.tq` files into C++ CodeStubAssembler (CSA) code (compiled by TurboFan) or Turboshaft reducers (compiled by Turboshaft). V8 is currently transitioning from CSA to Turboshaft for builtins. Torque also generates C++ headers that are used by both C++ and CSA code. +* **Benefits**: Strong typing, automatic generation of call descriptors, and safety checks. + +### 2. CodeStubAssembler (CSA) Builtins + +CSA is a low-level C++ API that allows writing code that directly generates TurboFan graphs. See [CodeStubAssembler](../codegen/code-stub-assembler.md) for details. +* **Files**: `builtins-*-gen.cc` and `.h` files in `src/builtins/`. +* **How it works**: CSA provides a programmatic way to emit TurboFan nodes (e.g., `Parameter`, `Load`, `Branch`, `CallRuntime`). It bypasses the JavaScript parser and AST, and generates machine code directly via TurboFan's backend. +* **Benefits**: Highly efficient, platform-independent (TurboFan handles the machine code generation), and has access to low-level V8 internals. + +### 3. C++ Builtins (Runtime) + +Standard C++ functions that can be called from JavaScript or other builtins. +* **Files**: `builtins-*.cc` files in `src/builtins/`. +* **How it works**: These are normal C++ functions registered with V8. They are called via a special runtime call mechanism. +* **Benefits**: Easiest to write, full access to C++ library and V8 complex internals. +* **Drawbacks**: Slower than Torque or CSA because of the boundary crossing between JS and C++. + +### 4. Architecture-Specific Assembler Builtins + +Low-level builtins written using V8's `MacroAssembler` in C++ for specific architectures. +* **Files**: `src/builtins/[arch]/builtins-[arch].cc`. +* **How it works**: Developers write C++ code that uses V8's `MacroAssembler` to emit raw machine instructions. +* **Benefits**: Ultimate performance, used for low-level entry points, trampolines, and operations where every instruction counts. +* **Constraint**: Architecture-specific builtins must be used for any operations that need to manipulate the stack (e.g., pushing arguments, setting up the interpreter stack frame) because TurboFan code assumes a fixed stack layout. +* **Drawbacks**: Must be written separately for every supported architecture (x64, arm, arm64, etc.). + +## How Builtins are Loaded + +Builtins are compiled during V8's build process (or at startup if snapshots are not used) and are stored in the **Snapshot**. This ensures that V8 starts up with all standard library functions ready to execute without needing to parse or compile them. + +They are shared across all Isolates and contexts in a single process. + +## Embedding and Copying + +To reduce startup time and memory sharing across Isolates, V8 **embeds** builtins into the binary. + +* **Embedded Blob**: Builtins are compiled and written into a dedicated section of the binary (the embedded blob). +* **Sharing**: This allows multiple Isolates in the same process to share the same executable code for builtins, saving memory. + +### Copying Out (Remapping) + +Under certain conditions, V8 may **copy** or **remap** the embedded builtins into the `CodeRange` of a specific Isolate: + +* **Short Builtin Calls**: On some architectures (like x64 and arm64), function calls have a limited relative range. If generated code in the `CodeRange` needs to call a builtin, and the embedded blob is too far away in memory, V8 cannot use efficient PC-relative calls. +* **The Solution**: If `v8_flags.short_builtin_calls` is enabled (often depending on available physical memory), V8 will copy or remap the embedded builtins into the `CodeRange` so they are close to the generated code. +* **Remapping vs Copying**: + * If the OS supports it (e.g., via page remapping), V8 will **remap** the pages to avoid making them private dirty memory, keeping them shared. + * If not supported, V8 falls back to **copying** them via `memcpy`, which increases private memory usage. + +--- + +## See Also +- `docs/torque/architecture.md`: Deep dive into Torque. +- `src/builtins/`: Source directory for builtins. diff --git a/deps/v8/docs/builtins/torque-tutorial.md b/deps/v8/docs/builtins/torque-tutorial.md new file mode 100644 index 00000000000000..951161b30a7d0f --- /dev/null +++ b/deps/v8/docs/builtins/torque-tutorial.md @@ -0,0 +1,126 @@ +--- +title: 'Torque Tutorial' +description: 'This document is intended as an introduction to writing Torque builtins, and is targeted towards V8 developers.' +--- + +This document is intended as an introduction to writing Torque builtins, and is targeted towards V8 developers. Torque replaces CodeStubAssembler as the recommended way to implement new builtins. See [CodeStubAssembler Tutorial](../codegen/csa-tutorial.md) for the CSA version of this guide. + +## Writing a Torque builtin + +In this section, we will write a simple CSA builtin that takes a single argument, and returns whether it represents the number `42`. The builtin is exposed to JS by installing it on the `Math` object (because we can). + +This example demonstrates: + +- Creating a Torque builtin with JavaScript linkage, which can be called like a JS function. +- Using Torque to implement simple logic: type distinction, Smi and heap-number handling, conditionals. +- Installation of the CSA builtin on the `Math` object. + +In case you’d like to follow along locally, the following code is based off revision [589af9f2](https://chromium.googlesource.com/v8/v8/+/589af9f257166f66774b4fb3008cd09f192c2614). + +## Defining `MathIs42` + +Torque code is located in `src/builtins/*.tq` files, roughly organized by topic. Since we will be writing a `Math` builtin, we’ll put our definition into `src/builtins/math.tq`. + +```torque +namespace math { + javascript builtin MathIs42( + js-implicit context: NativeContext, receiver: JSAny)(x: JSAny): Boolean { + // At this point, x can be basically anything - a Smi, a HeapNumber, + // undefined, or any other arbitrary JS object. ToNumber_Inline is defined + // in CodeStubAssembler. It inlines a fast-path (if the argument is a number + // already) and calls the ToNumber builtin otherwise. + const number: Number = ToNumber_Inline(x); + // A typeswitch allows us to switch on the dynamic type of a value. The type + // system knows that a Number can only be a Smi or a HeapNumber, so this + // switch is exhaustive. + typeswitch (number) { + case (smi: Smi): { + // The result of smi == 42 is not a Javascript boolean, so we use a + // conditional to create a Javascript boolean value. + return smi == 42 ? True : False; + } + case (heapNumber: HeapNumber): { + return Convert(heapNumber) == 42 ? True : False; + } + } + } +} +``` + +We put the definition in the Torque namespace `math`, which already contains other math-related builtins. + +## Attaching `Math.is42` + +Builtin objects such as `Math` are set up mostly in `src/init/bootstrapper.cc` (with some setup occurring in `.js` files). Attaching our new builtin is simple: + +```cpp +// Existing code to set up Math, included here for clarity. +Handle math = factory->NewJSObject(cons, AllocationType::kOld); +JSObject::AddProperty(global, name, math, DONT_ENUM); +// […snip…] +SimpleInstallFunction(isolate_, math, "is42", Builtins::kMathIs42, 1, true); +``` + +Now that `is42` is attached, it can be called from JS: + +```bash +$ out/x64.optdebug/d8 +d8> Math.is42(42); +true +d8> Math.is42('42.0'); +true +d8> Math.is42(true); +false +d8> Math.is42({ valueOf: () => 42 }); +true +``` + +## Defining and calling a builtin with stub linkage + +Builtins can also be created with stub linkage (instead of JS linkage as we used above in `MathIs42`). Such builtins can be useful to extract commonly-used code into a separate code object that can be used by multiple callers, while the code is only produced once. Let’s extract the code that handles heap numbers into a separate builtin called `HeapNumberIs42`, and call it from `MathIs42`. + +The definition is also straightforward. The only difference to our builtin with Javascript linkage is that we omit the keyword `javascript` and there is no receiver argument. + +```torque +namespace math { + builtin HeapNumberIs42(implicit context: Context)(heapNumber: HeapNumber): + Boolean { + return Convert(heapNumber) == 42 ? True : False; + } + + javascript builtin MathIs42(js-implicit context: NativeContext, receiver: JSAny)( + x: JSAny): Boolean { + const number: Number = ToNumber_Inline(x); + typeswitch (number) { + case (smi: Smi): { + return smi == 42 ? True : False; + } + case (heapNumber: HeapNumber): { + // Instead of handling heap numbers inline, we now call our new builtin. + return HeapNumberIs42(heapNumber); + } + } + } +} +``` + +Why should you care about builtins at all? Why not leave the code inline (or extracted into macros for better readability)? + +An important reason is code space: builtins are generated at compile-time and included in the V8 snapshot or embedded into the binary. Extracting large chunks of commonly used code to separate builtins can quickly lead to space savings in the 10s to 100s of KBs. + +## Testing stub-linkage builtins + +Even though our new builtin uses a non-standard (at least non-C++) calling convention, it’s possible to write test cases for it. The following code can be added to `test/cctest/compiler/test-run-stubs.cc` to test the builtin on all platforms: + +```cpp +TEST(MathIsHeapNumber42) { + HandleAndZoneScope scope; + Isolate* isolate = scope.main_isolate(); + Heap* heap = isolate->heap(); + Zone* zone = scope.main_zone(); + + StubTester tester(isolate, zone, Builtins::kMathIs42); + Handle result1 = tester.Call(Handle(Smi::FromInt(0), isolate)); + CHECK(result1->BooleanValue()); +} +``` diff --git a/deps/v8/docs/codegen/assembler-architecture.md b/deps/v8/docs/codegen/assembler-architecture.md new file mode 100644 index 00000000000000..43598f61d698f3 --- /dev/null +++ b/deps/v8/docs/codegen/assembler-architecture.md @@ -0,0 +1,58 @@ +# Assembler and MacroAssembler Architecture + +This document explains V8's low-level code generation abstractions: the `Assembler` and `MacroAssembler`. These are used by all compilers (Sparkplug, Maglev, TurboFan) and hand-written builtins to emit machine code. + +## The Layered Approach + +V8 uses a multi-layered approach to code generation to balance performance, platform independence, and ease of use. + +### 1. `AssemblerBase` and `Assembler` + +At the lowest level is the `Assembler` (defined per architecture, e.g., `src/codegen/x64/assembler-x64.h`). + +* **`AssemblerBase`**: Provides common functionality like managing the instruction buffer, relocation information (reloc info), and code comments. +* **`Assembler`**: Implements the actual instruction encoding for a specific architecture. For example, on x64, calling `movq(rax, rbx)` directly emits the corresponding bytes into the buffer. +* **Role**: It is a 1:1 mapping to machine instructions. It does not perform any abstraction or simplification. + +### 2. `MacroAssembler` + +The `MacroAssembler` (also defined per architecture, e.g., `src/codegen/x64/macro-assembler-x64.h`) inherits from `Assembler` (via `MacroAssemblerBase` and often via a shared intermediate class like `SharedMacroAssembler` for related architectures). + +* **`MacroAssemblerBase`**: Contains platform-independent macro-assembler functionality (e.g., loading constants, root-relative addressing). +* **Role**: It provides higher-level "macro" instructions and common idioms that are composed of multiple raw instructions. +* **Abstractions**: + * **Runtime Calls**: `CallRuntime(Runtime::k...)` handles the complexity of setting up arguments and calling a C++ runtime function. + * **Frame Setup**: Methods to push/pop standard frame headers. + * **Pseudo-instructions**: Instructions that might not exist directly on the hardware but are common (e.g., `Push` on architectures that don't have a dedicated push instruction). + +## How They Are Used + +### In Compilers +Compilers like Maglev use the `MacroAssembler` in their `GenerateCode` methods. + +```cpp +void Int32AddWithOverflow::GenerateCode(MaglevAssembler* masm, const ProcessingState& state) { + Register left = ToRegister(LeftInput()); + Register right = ToRegister(RightInput()); + __ addl(left, right); // Raw assembler call via MacroAssembler + __ EmitEagerDeoptIf(overflow, DeoptimizeReason::kOverflow, this); // MacroAssembler helper +} +``` +*(Note: `MaglevAssembler` inherits from `MacroAssembler` and adds Maglev-specific helpers).* + +### In Builtins +Hand-written assembler builtins are written directly using the `MacroAssembler`. + +## The Instruction Buffer and Relocation + +The `Assembler` writes bytes into a growable buffer. Because code often contains references to objects or labels that are not yet fixed in memory, V8 uses **Relocation Information** (`RelocInfo`). + +* When the assembler emits a reference to a HeapObject or another code chunk, it records the position and the type of reference. +* When the code is finalized and moved to its permanent location in the heap, V8 "relocates" these references, patching the code with the actual memory addresses. + +--- + +## See Also +- `src/codegen/assembler.h`: Base class definitions. +- `src/codegen/x64/assembler-x64.h`: x64 specific assembler. +- `src/codegen/x64/macro-assembler-x64.h`: x64 specific macro-assembler. diff --git a/deps/v8/docs/codegen/code-stub-assembler.md b/deps/v8/docs/codegen/code-stub-assembler.md new file mode 100644 index 00000000000000..af5873e438ff59 --- /dev/null +++ b/deps/v8/docs/codegen/code-stub-assembler.md @@ -0,0 +1,40 @@ +# CodeStubAssembler (CSA) in V8 + +The `CodeStubAssembler` (CSA) is a critical component in V8's code generation pipeline. It provides a JavaScript-specific "macro-assembler" interface on top of V8's low-level `compiler::CodeAssembler`. + +## Overview + +CSA is used to write low-level code, such as builtins (e.g., `Promise` implementation details, parts of `Array.prototype` methods) and bytecode handlers for Ignition. While many builtins are now written in **Torque** (which generates CSA code), understanding CSA is still essential for working on V8's low-level components. It allows writing code in a way that is portable across all architectures supported by V8 (x64, ARM, ARM64, MIPS, etc.) without having to write raw machine code for each platform. + + +## How it Provides a Portable Interface + +### 1. Instruction Fallbacks +For many complex operations (e.g., `Float64Ceil`, `Float64Floor`, `PopulationCount`), CSA checks if the target architecture supports native instructions for these operations (e.g., via `IsFloat64RoundUpSupported()`). +* **If supported**: It generates the specific machine instruction directly. +* **If not supported**: It provides a software fallback implementation in C++ that generates a sequence of simpler operations to achieve the same result. +This ensures that the same CSA code can run on all platforms, regardless of their hardware capabilities. + +### 2. Abstraction of Data Representation +CSA abstracts away platform-specific details like pointer size, pointer compression, and `Smi` (Small Integer) representation. +* For example, arithmetic operations on Smis (like `SmiAdd`) automatically handle whether Smis are 31-bit or 32-bit and whether they need to be shifted or masked, based on the build configuration. + +### 3. Type Safety with TNodes +While it feels like assembly, it is strongly typed at the C++ level using `TNode` (e.g., `TNode`, `TNode`, `TNode`). This prevents many common low-level errors by ensuring that operations are only performed on compatible types at compile time. + +### 4. High-Level Abstractions +CSA provides higher-level operations that are common in JavaScript execution but would be tedious to write in raw assembly: +* Allocating objects in the heap (`AllocateInNewSpace`). +* Checking object types and map transitions. +* Calling JavaScript functions and other builtins. +## Torque and CSA + +V8 now uses a domain-specific language called **Torque** for writing many of its builtins. Torque code (files with `.tq` extension) is compiled by the Torque compiler into C++ code that uses the `CodeStubAssembler` interface. +* **Torque** provides a higher-level, more readable syntax with strong typing. +* **CSA** is the underlying implementation layer that Torque generates. + +For more details on Torque, see the [Torque documentation](../torque.md). + +## File Structure +* `src/codegen/code-stub-assembler.h`: Header file defining the CSA interface. +* `src/codegen/code-stub-assembler.cc`: Implementation of the CSA operations. diff --git a/deps/v8/docs/codegen/csa-tutorial.md b/deps/v8/docs/codegen/csa-tutorial.md new file mode 100644 index 00000000000000..eefd25ac599114 --- /dev/null +++ b/deps/v8/docs/codegen/csa-tutorial.md @@ -0,0 +1,232 @@ +--- +title: 'CodeStubAssembler Tutorial' +description: 'This document is intended as an introduction to writing CodeStubAssembler builtins, and is targeted towards V8 developers.' +--- + +This document is intended as an introduction to writing CodeStubAssembler builtins, and is targeted towards V8 developers. + +:::note +**Note:** [Torque](/docs/torque) replaces CodeStubAssembler as the recommended way to implement new builtins. See [Torque builtins](/docs/torque-builtins) for the Torque version of this guide. +::: + +## Builtins + +In V8, builtins can be seen as chunks of code that are executable by the VM at runtime. A common use case is to implement the functions of builtin objects (such as RegExp or Promise), but builtins can also be used to provide other internal functionality (e.g. as part of the IC system). + +V8’s builtins can be implemented using a number of different methods (each with different trade-offs): + +- **Platform-dependent assembly language**: can be highly efficient, but need manual ports to all platforms and are difficult to maintain. +- **C++**: very similar in style to runtime functions and have access to V8’s powerful runtime functionality, but usually not suited to performance-sensitive areas. +- **JavaScript**: concise and readable code, access to fast intrinsics, but frequent usage of slow runtime calls, subject to unpredictable performance through type pollution, and subtle issues around JS semantics. *(Mostly deprecated now for new builtins, replaced by Torque).* +- **CodeStubAssembler**: provides efficient low-level functionality that is very close to assembly language while remaining platform-independent and preserving readability. +- **Torque**: The recommended high-level language that generates CSA code. + +The remaining document focuses on CodeStubAssembler and gives a brief tutorial for developing a simple CodeStubAssembler (CSA) builtin exposed to JavaScript. + +## CodeStubAssembler + +V8’s CodeStubAssembler is a custom, platform-agnostic assembler that provides low-level primitives as a thin abstraction over assembly, but also offers an extensive library of higher-level functionality. + +```cpp +// Low-level: +// Loads the pointer-sized data at addr into value. +TNode addr = /* ... */; +TNode value = Load(addr); + +// And high-level: +// Performs the JS operation ToString(object). +// ToString semantics are specified at https://tc39.es/ecma262/#sec-tostring. +TNode context = /* ... */; +TNode object = /* ... */; +TNode string = ToString(context, object); +``` + +CSA builtins run through part of the TurboFan compilation pipeline (including block scheduling and register allocation, but notably not through optimization passes) which then emits the final executable code. + +## Writing a CodeStubAssembler builtin + +In this section, we will write a simple CSA builtin that takes a single argument, and returns whether it represents the number `42`. The builtin is exposed to JS by installing it on the `Math` object (because we can). + +This example demonstrates: + +- Creating a CSA builtin with JavaScript linkage, which can be called like a JS function. +- Using CSA to implement simple logic: Smi and heap-number handling, conditionals, and calls to TFS builtins. +- Using CSA Variables (`TVARIABLE`). +- Installation of the CSA builtin on the `Math` object. + +## Declaring `MathIs42` + +Builtins are declared in the `BUILTIN_LIST_BASE` macro in `src/builtins/builtins-definitions.h`. To create a new CSA builtin with JS linkage and one parameter named `X`: + +```cpp +#define BUILTIN_LIST_BASE(CPP, API, TFJ, TFC, TFS, TFH, ASM, DBG) \ + // […snip…] + TFJ(MathIs42, 1, kX) \ + // […snip…] +``` + +Note that `BUILTIN_LIST_BASE` takes several different macros that denote different builtin kinds (see inline documentation for more details). CSA builtins specifically are split into: + +- **TFJ**: JavaScript linkage. +- **TFS**: Stub linkage. +- **TFC**: Stub linkage builtin requiring a custom interface descriptor (e.g. if arguments are untagged or need to be passed in specific registers). +- **TFH**: Specialized stub linkage builtin used for IC handlers. + +## Defining `MathIs42` + +Builtin definitions are located in `src/builtins/builtins-*-gen.cc` files, roughly organized by topic. Since we will be writing a `Math` builtin, we’ll put our definition into `src/builtins/builtins-math-gen.cc`. + +```cpp +// TF_BUILTIN is a convenience macro that creates a new subclass of the given +// assembler behind the scenes. +TF_BUILTIN(MathIs42, MathBuiltinsAssembler) { + // Load the current function context (an implicit argument for every stub) + // and the X argument. Note that we can refer to parameters by the names + // defined in the builtin declaration. + TNode const context = Parameter(Descriptor::kContext); + TNode const x = Parameter(Descriptor::kX); + + // At this point, x can be basically anything - a Smi, a HeapNumber, + // undefined, or any other arbitrary JS object. Let’s call the ToNumber + // builtin to convert x to a number we can use. + // CallBuiltin can be used to conveniently call any CSA builtin. + TNode const number = CAST(CallBuiltin(Builtins::kToNumber, context, x)); + + // Create a CSA variable to store the resulting value. + TVARIABLE(Object, var_result); + + // We need to define a couple of labels which will be used as jump targets. + Label if_issmi(this), if_isheapnumber(this), out(this); + + // ToNumber always returns a number. We need to distinguish between Smis + // and heap numbers - here, we check whether number is a Smi and conditionally + // jump to the corresponding labels. + Branch(TaggedIsSmi(number), &if_issmi, &if_isheapnumber); + + // Binding a label begins generating code for it. + BIND(&if_issmi); + { + // SelectBooleanConstant returns the JS true/false values depending on + // whether the passed condition is true/false. The result is bound to our + // var_result variable, and we then unconditionally jump to the out label. + TNode smi_number = CAST(number); + var_result.Bind(SelectBooleanConstant(SmiEqual(smi_number, SmiConstant(42)))); + Goto(&out); + } + + BIND(&if_isheapnumber); + { + // ToNumber can only return either a Smi or a heap number. Just to make sure + // we add an assertion here that verifies number is actually a heap number. + CSA_ASSERT(this, IsHeapNumber(number)); + + // Heap numbers wrap a floating point value. We need to explicitly extract + // this value, perform a floating point comparison, and again bind + // var_result based on the outcome. + TNode hn_number = CAST(number); + TNode const value = LoadHeapNumberValue(hn_number); + TNode const is_42 = Float64Equal(value, Float64Constant(42)); + var_result.Bind(SelectBooleanConstant(is_42)); + Goto(&out); + } + + BIND(&out); + { + TNode const result = var_result.value(); + CSA_ASSERT(this, IsBoolean(result)); + Return(result); + } +} +``` + +## Attaching `Math.Is42` + +Builtin objects such as `Math` are set up mostly in `src/init/bootstrapper.cc`. Attaching our new builtin is simple: + +```cpp +// Existing code to set up Math, included here for clarity. +Handle math = factory->NewJSObject(cons, TENURED); +JSObject::AddProperty(global, name, math, DONT_ENUM); +// […snip…] +SimpleInstallFunction(math, "is42", Builtins::kMathIs42, 1, true); +``` + +Now that `Is42` is attached, it can be called from JS: + +```bash +$ out/debug/d8 +d8> Math.is42(42); +true +d8> Math.is42('42.0'); +true +d8> Math.is42(true); +false +d8> Math.is42({ valueOf: () => 42 }); +true +``` + +## Defining and calling a builtin with stub linkage + +CSA builtins can also be created with stub linkage (instead of JS linkage as we used above in `MathIs42`). Such builtins can be useful to extract commonly-used code into a separate code object that can be used by multiple callers, while the code is only produced once. Let’s extract the code that handles heap numbers into a separate builtin called `MathIsHeapNumber42`, and call it from `MathIs42`. + +Defining and using TFS stubs is easy; declaration are again placed in `src/builtins/builtins-definitions.h`: + +```cpp +#define BUILTIN_LIST_BASE(CPP, API, TFJ, TFC, TFS, TFH, ASM, DBG) \ + // […snip…] + TFS(MathIsHeapNumber42, kX) \ + TFJ(MathIs42, 1, kX) \ + // […snip…] +``` + +Note that currently, order within `BUILTIN_LIST_BASE` does matter. Since `MathIs42` calls `MathIsHeapNumber42`, the former needs to be listed after the latter. + +The definition is also straightforward. In `src/builtins/builtins-math-gen.cc`: + +```cpp +// Defining a TFS builtin works exactly the same way as TFJ builtins. +TF_BUILTIN(MathIsHeapNumber42, MathBuiltinsAssembler) { + TNode const x = Parameter(Descriptor::kX); + CSA_ASSERT(this, IsHeapNumber(x)); + TNode hn_x = CAST(x); + TNode const value = LoadHeapNumberValue(hn_x); + TNode const is_42 = Float64Equal(value, Float64Constant(42)); + Return(SelectBooleanConstant(is_42)); +} +``` + +Finally, let’s call our new builtin from `MathIs42`: + +```cpp +TF_BUILTIN(MathIs42, MathBuiltinsAssembler) { + // […snip…] + BIND(&if_isheapnumber); + { + // Instead of handling heap numbers inline, we now call into our new TFS stub. + var_result.Bind(CallBuiltin(Builtins::kMathIsHeapNumber42, context, number)); + Goto(&out); + } + // […snip…] +} +``` + +Why should you care about TFS builtins at all? Why not leave the code inline (or extracted into a helper method for better readability)? + +An important reason is code space: builtins are generated at compile-time and included in the V8 snapshot, thus unconditionally taking up (significant) space in every created isolate. Extracting large chunks of commonly used code to TFS builtins can quickly lead to space savings in the 10s to 100s of KBs. + +## Testing stub-linkage builtins + +Even though our new builtin uses a non-standard (at least non-C++) calling convention, it’s possible to write test cases for it. The following code can be added to `test/cctest/compiler/test-run-stubs.cc` to test the builtin on all platforms: + +```cpp +TEST(MathIsHeapNumber42) { + HandleAndZoneScope scope; + Isolate* isolate = scope.main_isolate(); + Heap* heap = isolate->heap(); + Zone* zone = scope.main_zone(); + + StubTester tester(isolate, zone, Builtins::kMathIs42); + Handle result1 = tester.Call(Handle(Smi::FromInt(0), isolate)); + CHECK(result1->BooleanValue()); +} +``` diff --git a/deps/v8/docs/committer-responsibility.md b/deps/v8/docs/committer-responsibility.md new file mode 100644 index 00000000000000..68e7b4ab827e03 --- /dev/null +++ b/deps/v8/docs/committer-responsibility.md @@ -0,0 +1,42 @@ +--- +title: 'Responsibilities of V8 committers and reviewers' +description: 'This document lists guidelines for V8 contributors.' +--- +When you’re committing to the V8 repositories, ensure that you follow these guidelines (adapted from ): + +1. Find the right reviewer for your changes and for patches you’re asked to review. +1. Be available on IM and/or email before and after you land the change. +1. Watch the [waterfall](https://ci.chromium.org/p/v8/g/main/console) until all bots turn green after your change. +1. When landing a TBR change (To Be Reviewed), make sure to notify the people whose code you’re changing. Usually just send the review e-mail. + +In short, do the right thing for the project, not the easiest thing to get code committed, and above all: use your best judgement. + +**Don’t be afraid to ask questions. There is always someone who will immediately read messages sent to the v8-committers mailing list who can help you.** + +## Changes with multiple reviewers + +There are occasionally changes with a lot of reviewers on them, since sometimes several people might need to be in the loop for a change because of multiple areas of responsibility and expertise. + +The problem is that without some guidelines, there’s no clear responsibility given in these reviews. + +If you’re the sole reviewer on a change, you know you have to do a good job. When there are three other people, you sometimes assume that somebody else must have looked carefully at some part of the review. Sometimes all the reviewers think this and the change isn’t reviewed properly. + +In other cases, some reviewers say “LGTM” for a patch, while others are still expecting changes. The author can get confused as to the status of the review, and some patches have been checked in where at least one reviewer expected further changes before committing. + +At the same time, we want to encourage many people to participate in the review process and keep tabs on what’s going on. + +So, here are some guidelines to help clarify the process: + +1. When a patch author requests more than one reviewer, they should make clear in the review request email what they expect the responsibility of each reviewer to be. For example, you could write this in the email: + + ``` + - larry: bitmap changes + - sergey: process hacks + - everybody else: FYI + ``` + +1. In this case, you might be on the review list because you’ve asked to be in the loop for multiprocess changes, but you wouldn’t be the primary reviewer and the author and other reviewers wouldn’t be expecting you to review all the diffs in detail. +1. If you get a review that includes many other people, and the author didn’t do (1), please ask them what part you’re responsible for if you don’t want to review the whole thing in detail. +1. The author should wait for approval from everybody on the reviewer list before checking in. +1. People who are on a review without clear review responsibility (i.e. drive-by reviews) should be super responsive and not hold up the review. The patch author should feel free to ping them mercilessly if they are. +1. If you’re an “FYI” person on a review and you didn’t actually review in detail (or at all), but don’t have a problem with the patch, note this. You could say something like “rubber stamp” or “ACK” instead of “LGTM”. This way the real reviewers know not to trust that you did their work for them, but the author of the patch knows they don’t have to wait for further feedback from you. Hopefully we can still keep everybody in the loop but have clear ownership and detailed reviews. It might even speed up some changes since you can quickly “ACK” changes you don’t care about, and the author knows they don’t have to wait for feedback from you. diff --git a/deps/v8/docs/compile-arm64.md b/deps/v8/docs/compile-arm64.md new file mode 100644 index 00000000000000..57b2ecfb55cf9f --- /dev/null +++ b/deps/v8/docs/compile-arm64.md @@ -0,0 +1,86 @@ +--- +title: 'Compiling on Arm64 Linux' +description: 'Tips and tricks to build V8 natively on Arm64 Linux' +--- +If you've gone through instructions on how to [check out](/docs/source-code) and [build](/docs/build-gn) V8 on a machine that is neither x86 nor an Apple Silicon Mac, you may have ran into a bit of trouble, due to the build system downloading native binaries and then not being able to run them. However, even though using an Arm64 Linux machine to work on V8 is __not officially supported__, overcoming those hurdles is pretty straightforward. + +## Bypassing `vpython` + +`fetch v8`, `gclient sync` and other `depot_tools` commands use a wrapper for python called "vpython". If you see errors related to it, you can define the following variable to use the system's python installation instead: + +```bash +export VPYTHON_BYPASS="manually managed python not supported by chrome operations" +``` + +## Compatible `ninja` binary + +The first thing to do is to make sure we use a native binary for `ninja`, which we pick instead of the one in `depot_tools`. A simple way to do this is to tweak your PATH as follows when installing `depot_tools`: + +```bash +export PATH=$PATH:/path/to/depot_tools +``` + +This way, you'll be able to use your system's `ninja` installation, given it's likely to be available. Although if it isn't you can [build it from source](https://github.com/ninja-build/ninja#building-ninja-itself). + +## Compiling clang + +By default, V8 will want to use its own build of clang that may not run on your machine. You could tweak GN arguments in order to [use the system's clang or GCC](#system_clang_gcc), however, you may want to use the same clang as upstream, as it will be the most supported version. + +You can build it locally directly from the V8 checkout: + +```bash +./tools/clang/scripts/build.py --without-android --without-fuchsia \ + --host-cc=gcc --host-cxx=g++ \ + --gcc-toolchain=/usr \ + --use-system-cmake --disable-asserts +``` + +## Setting up GN arguments manually + +Convenience scripts may not work by default, instead you'll have to set GN arguments manually following the [manual](/docs/build-gn#gn) workflow. You can get the usual "release", "optdebug" and "debug" configurations with the following arguments: + +- `release` + +```bash +is_debug=false +``` + +- `optdebug` + +```bash +is_debug=true +v8_enable_backtrace=true +v8_enable_slow_dchecks=true +``` + +- `debug` + +```bash +is_debug=true +v8_enable_backtrace=true +v8_enable_slow_dchecks=true +v8_optimized_debug=false +``` + +## Using the system's clang or GCC { #system_clang_gcc } + +Building with GCC is only a case of disabling compiling with clang: + +```bash +is_clang=false +``` + +Note that by default, V8 will link using `lld`, which requires a recent version of GCC. You can use `use_lld=false` to switch to the gold linker, or additionally use `use_gold=false` to use `ld`. + +If you'd like to use the clang that's installed with your system, say in `/usr`, you can use the following arguments: + +```bash +clang_base_path="/usr" +clang_use_chrome_plugins=false +``` + +However, given the system's clang version may not be well supported, you're likely to deal with warnings, such as unknown compiler flags. In this case it's useful to stop treating warnings as errors with: + +```bash +treat_warnings_as_errors=false +``` diff --git a/deps/v8/docs/compiler/concurrency-and-background-compilation.md b/deps/v8/docs/compiler/concurrency-and-background-compilation.md new file mode 100644 index 00000000000000..97084f2b8e5789 --- /dev/null +++ b/deps/v8/docs/compiler/concurrency-and-background-compilation.md @@ -0,0 +1,62 @@ +# Concurrency and Background Compilation + +This document explains how V8 achieves high performance by offloading compilation and parsing to background threads, and the mechanisms used to keep this concurrent execution safe. + +## Background Compilation + +To keep the main thread (which runs JavaScript and handles UI interaction) responsive, V8 offloads as much work as possible to background threads. + +### 1. Background Parsing and Bytecode Generation +V8 can parse JavaScript source code and generate Ignition bytecode on background threads. This means that by the time a script is actually executed, its bytecode may already be prepared. + +### 2. Background Optimization +Both Maglev and TurboFan (including its Turboshaft pipeline) perform their heavy optimization work on background threads. +* **Main Thread**: Identifies hot functions, creates a compilation job, and triggers the background thread. +* **Background Thread**: Reads the IR, applies optimizations, and generates machine code. +* **Main Thread**: Finally installs the generated code. + +## Isolation: `LocalIsolate` and `LocalHeap` + +Background threads cannot safely access the main `Isolate` or `Heap` without heavy locking, which would destroy performance. Instead, V8 provides "local" equivalents: + +* **`LocalIsolate`**: A thread-local view of the Isolate. It provides access to a `LocalHeap` and handles background-safe operations. +* **`LocalHeap`**: A thread-local heap that allows the background thread to allocate objects (in its own Linear Allocation Areas) and manage handles without locking the main heap. + +## Safety: `JSHeapBroker` and `HeapRefs` + +A major challenge in background optimization is that the background thread needs to know about the structure of JavaScript objects (Maps, shapes, constants) to optimize effectively. However, reading these objects directly from the background thread is unsafe because: +1. The Garbage Collector might move them. +2. The main thread might modify them concurrently. + +To solve this, V8 uses the **`JSHeapBroker`** and a system of **`HeapRefs`**: + +1. **`HeapRefs`**: Instead of using direct pointers (`Tagged`), optimizing compilers use **Refs** (e.g., `ObjectRef`, `MapRef`, `JSFunctionRef`). +2. **Concurrent Reading and Serialization**: Modern V8 allows `HeapRefs` to read the live heap concurrently for most kinds of data, rather than relying on a full snapshot. + * **Serialization** is only used for things that are actually unsafe to read concurrently. + * Many objects are marked as **`NEVER_SERIALIZED`** and are always read live from the background thread. + * Some data structures might be read live but using different algorithms to ensure safety (e.g., searching descriptor arrays linearly instead of using a binary search, to avoid issues with concurrent modifications). + +This approach ensures that the background compiler sees a safe view of the heap data while minimizing the overhead of snapshotting. + +## Synchronization: Safepoints and Parking + +Even with isolation, the Garbage Collector occasionally needs to stop all threads to perform a collection. V8 uses a **Safepoint** mechanism to coordinate this. + +### Safepoints +Threads running JavaScript or accessing the heap must regularly check if a safepoint has been requested (by calling `Safepoint()`). When requested, they pause execution until the GC is complete. + +### Parking +Background threads (like a compiler thread) might spend a long time doing pure computation without needing to access the heap. +* **`Parked` State**: A thread can explicitly "park" itself. Instead of creating a `ParkedScope` directly (its constructors are private), threads should use `ExecuteWhileParked` (or similar methods on `LocalHeap`), which provides a `const ParkedScope&` witness to the callback. While parked, the thread promises *not* to access the heap. +* **GC Independence**: The GC does not need to wait for parked threads to reach a safepoint. It can proceed immediately, ignoring them. +* **Unparking**: If a parked thread needs to access the heap again, it must "unpark". If a GC is currently in progress, the unpark call will block until the GC finishes. + +This allows long-running background tasks to proceed without delaying garbage collection. + +--- + +## See Also +- `src/heap/local-heap.h`: Definition of `LocalHeap` and parking states. +- `src/heap/parked-scope.h`: Definition of `ParkedScope` and related guards. +- `src/compiler/js-heap-broker.h`: The heap broker for background optimization. +- [Tiering](../runtime/tiering.md): How V8 decides to optimize functions. diff --git a/deps/v8/docs/compiler/maglev/compiler-maglev-regalloc.md b/deps/v8/docs/compiler/maglev/compiler-maglev-regalloc.md new file mode 100644 index 00000000000000..7c91a92db77f06 --- /dev/null +++ b/deps/v8/docs/compiler/maglev/compiler-maglev-regalloc.md @@ -0,0 +1,77 @@ +# Maglev Register Allocator: Linear Scan and Constraints + +This document provides a deep dive into Maglev's register allocator, explaining how it works and how IR nodes communicate their register requirements. + +## The Allocator: `StraightForwardRegisterAllocator` + +Maglev uses a linear scan register allocator called `StraightForwardRegisterAllocator` (declared in `src/maglev/maglev-regalloc.h` and implemented in `src/maglev/maglev-regalloc.cc`). It is designed to be fast and operates on a single IR level. + +The allocator maintains the state of registers (free, used, blocked) using `RegisterFrameState`. It processes the graph block by block, and node by node within each block. + +## How Nodes Register Their Needs + +Before the actual register allocation pass, Maglev runs a pre-allocation phase called `ValueLocationConstraintProcessor` (in `src/maglev/maglev-pre-regalloc-codegen-processors.h`). This processor iterates over all nodes and calls their `SetValueLocationConstraints()` method. + +In `SetValueLocationConstraints()`, a node specifies what kind of location (register, stack, or specific register) it requires for its inputs and where it wants its output to be placed. + +### Constraint Helpers + +Nodes use a set of inline helper functions (defined in `src/maglev/maglev-ir-inl.h`) to set these constraints. These helpers modify the `InputLocation` or result operand of the node, setting them as `compiler::UnallocatedOperand` with specific policies. + +Here are the common helpers: + +#### For Inputs: +* `UseRegister(Input input)`: The input must be in a general-purpose register at the end of the node's execution. +* `UseAndClobberRegister(Input input)`: The input must be in a register at the start, but that register may be clobbered by the node. +* `UseAny(Input input)`: The input can be in a register, stack slot, or be a constant. +* `UseFixed(Input input, Register reg)`: The input must be in the specific register `reg`. +* `UseFixed(Input input, DoubleRegister reg)`: The input must be in the specific double register `reg`. +* `UseAndClobberFixed(Input input, Register reg)`: The input must be in the specific register `reg` at the start, but that register may be clobbered by the node. + +#### For Outputs (Results): +* `DefineAsRegister(Node* node)`: The result will be placed in a general-purpose register. +* `DefineAsFixed(Node* node, Register reg)`: The result will be placed in the specific register `reg`. +* `DefineAsConstant(Node* node)`: The result is a constant and doesn't need a register. +* `DefineSameAsFirst(Node* node)`: The result will be placed in the same register as the first input. This is common for operations that modify their first operand in-place (e.g., `addl` on x86). + +### Example: `Int32AddWithOverflow` + +Here is how `Int32AddWithOverflow` registers its needs in `src/maglev/x64/maglev-ir-x64.cc`: + +```cpp +void Int32AddWithOverflow::SetValueLocationConstraints() { + UseRegister(LeftInput()); + if (TryGetInt32ConstantInput(kRightIndex)) { + UseAny(RightInput()); + } else { + UseRegister(RightInput()); + } + DefineSameAsFirst(this); +} +``` + +* It requests a register for the `LeftInput`. +* If the `RightInput` is a constant, it allows `UseAny` (it can be an immediate value in the instruction). Otherwise, it requests a register. +* It uses `DefineSameAsFirst` because the x64 `add` instruction typically overwrites its first operand (`add eax, ebx`). + +## The Allocation Process + +When `StraightForwardRegisterAllocator::AllocateNode` runs, it processes these constraints in a specific order to minimize conflicts and spills: + +1. **Assign Inputs**: `AssignInputs(node)` handles input operands: + * **Fixed Inputs**: Processed first (e.g., `UseFixed`). These are rigid constraints. + * **Fixed Temporaries**: Registers needed as scratch space. + * **Arbitrary Register Inputs**: Processed next (e.g., `UseRegister`). The allocator tries to find free registers or spills values to make room. + * **Arbitrary Temporaries**: Non-fixed scratch registers. + * **Any Inputs**: Processed last (e.g., `UseAny`). These are the most flexible. +2. **Allocate Node Result**: `AllocateNodeResult` handles the output constraint (e.g., `DefineSameAsFirst` or `DefineAsRegister`). +3. **Allocate Deopts**: Handles inputs needed for eager and lazy deoptimization, ensuring they are loadable. + +By separating constraint specification from the allocation algorithm, Maglev keeps node definitions clean while allowing the allocator to make globally informed decisions about register usage. + +--- + +## See Also +- `src/maglev/maglev-regalloc.h`: Register allocator declaration. +- `src/maglev/maglev-regalloc.cc`: Register allocator implementation. +- `src/maglev/maglev-ir-inl.h`: Constraint helper functions. diff --git a/deps/v8/docs/compiler/maglev/compiler-maglev.md b/deps/v8/docs/compiler/maglev/compiler-maglev.md new file mode 100644 index 00000000000000..ad129b44ecfd07 --- /dev/null +++ b/deps/v8/docs/compiler/maglev/compiler-maglev.md @@ -0,0 +1,115 @@ +# Maglev: V8's Mid-Tier Optimizing Compiler + +Maglev is V8's mid-tier optimizing compiler. It is designed to be a fast optimizing compiler that provides a significant performance boost over Sparkplug while compiling much faster than TurboFan. + +## Design Philosophy + +Maglev is designed to be a "fast" optimizing compiler. It fills the gap between Sparkplug (very fast, no optimizations) and TurboFan (slow, highly optimized). To achieve this, Maglev makes several deliberate design choices: + +1. **Minimize Phases**: Unlike TurboFan, which has dozens of optimization and lowering phases, Maglev keeps the pipeline as short as possible. +2. **Single IR**: Maglev uses a single level of Intermediate Representation (IR) from graph building to code generation. There are no multiple tiers of lowering (e.g., JS -> Simplified -> Machine). +3. **Direct Code Generation**: IR nodes generate machine code directly via the `MacroAssembler`, without a separate instruction selection phase. + +## Architecture + +Maglev is a **graph-based compiler** that uses a Single Static Assignment (SSA) style Intermediate Representation (IR). + +* **Maglev IR**: The graph consists of nodes representing operations and edges representing data and control flow. +* **Type Inference**: Maglev makes use of the type feedback collected by Ignition in the `FeedbackVector`. It uses this feedback to speculate on types and generate specialized code (e.g., assuming a property access is monomorphic). +* **Register Allocation**: Maglev uses a linear scan register allocator to assign physical registers to IR nodes. See [Maglev Register Allocation](compiler-maglev-regalloc.md) for details. + +## The Pipeline (Minimizing Phases) + +The entire compilation pipeline in `src/maglev/maglev-compiler.cc` consists of only a few major steps: + +1. **Graph Building**: `MaglevGraphBuilder` iterates over bytecode and builds the graph in a single pass, performing abstract interpretation and inserting checks based on type feedback. +2. **Inlining**: Small functions are inlined if enabled. +3. **Optimization Passes**: A few selected, fast passes (Truncation propagation, Loop optimization, Phi representation selection). +4. **Dead Code Marking**: Identifies used nodes and propagates usage information. +5. **Pre-Register Allocation Processing**: Sweeps dead nodes, collects value location constraints, and computes live ranges. +6. **Register Allocation**: A fast linear scan allocator (`StraightForwardRegisterAllocator`). +7. **Code Assembly**: `MaglevCodeGenerator` iterates over the graph and emits code to a buffer. + +## Graph Building + +The core of Maglev's frontend is the `MaglevGraphBuilder` (defined in `src/maglev/maglev-graph-builder.h`). + +1. **Bytecode Iteration**: Like Sparkplug, it iterates through the `BytecodeArray`. +2. **Abstract Interpretation**: It maintains an `InterpreterFrameState` which maps Ignition's virtual registers and accumulator to Maglev IR nodes (`ValueNode`). +3. **Node Creation**: For each bytecode, it creates corresponding IR nodes and links them into the graph. For example, an `Add` bytecode might create an `Int32AddWithOverflow` node if feedback suggests integer addition. +4. **Feedback Usage**: It queries the `JSHeapBroker` to read feedback and make decisions about inlining and specialized operations. + +## Single IR Level + +In TurboFan, a graph starts with high-level JavaScript operators, gets lowered to "Simplified" operators (handling types like numbers and strings), and finally to "Machine" operators (raw pointers, integers). + +Maglev bypasses this multi-tiered lowering. Its IR nodes represent operations that are already close to machine level but still retain enough high-level information to support deoptimization. + +For example, `Int32AddWithOverflow` is a single node that represents an integer addition that might fail and trigger a deopt. It doesn't need to be lowered further; it knows how to generate the code to perform the addition and check the overflow flag. + +## Direct Code Generation + +The most striking difference between Maglev and TurboFan is how they generate machine code. + +In TurboFan, the graph is passed to an **Instruction Selector**, which matches patterns of nodes to machine instructions, creating a new "Instruction" list, which is then scheduled and colored by the register allocator. + +In Maglev, after register allocation, the `MaglevCodeGenerator` simply iterates through the basic blocks and the nodes within them. Each node implements a `GenerateCode` method. + +Here is an example from `src/maglev/x64/maglev-ir-x64.cc` for `Int32AddWithOverflow`: + +```cpp +void Int32AddWithOverflow::GenerateCode(MaglevAssembler* masm, + const ProcessingState& state) { + Register left = ToRegister(LeftInput()); + if (!RightInput().operand().IsRegister()) { + auto right_const = TryGetInt32ConstantInput(kRightIndex); + DCHECK(right_const); + __ addl(left, Immediate(*right_const)); // Emits x64 'add' + } else { + Register right = ToRegister(RightInput()); + __ addl(left, right); // Emits x64 'add' + } + // None of the mutated input registers should be a register input into the + // eager deopt info. + DCHECK_REGLIST_EMPTY(RegList{left} & + GetGeneralRegistersUsedAsInputs(eager_deopt_info())); + // Emit eager deopt if overflow flag is set + __ EmitEagerDeoptIf(overflow, DeoptimizeReason::kOverflow, this); +} +``` + +The `__` macro expands to `masm->`, which is the `MaglevAssembler` (inheriting from `MacroAssembler`). The node directly emits the `addl` instruction and the conditional jump for deoptimization. + +This direct approach eliminates the overhead of instruction selection and intermediate lists, making compilation extremely fast. + +## Deoptimization Support + +A key requirement for Maglev is the ability to deoptimize back to the interpreter. This means that even though Maglev IR nodes are close to machine level, they must retain enough information to reconstruct the interpreter state. + +Maglev achieves this by attaching `EagerDeoptInfo` or `LazyDeoptInfo` to nodes that can fail or side-effect. +- **Eager Deoptimization**: Happens when a check fails (e.g., type check, overflow). The execution jumps to a deopt exit, which uses the `EagerDeoptInfo` to reconstruct the frame state at the point of failure. +- **Lazy Deoptimization**: Happens when a call returns and the environment has changed in a way that makes the optimized code invalid. + +The `DeoptFrame` stored in these info structures captures the state of the interpreter frames (parameters, registers, accumulator) at that specific point in the execution. This allows the deoptimizer to translate the current machine state back into interpreter frames. + +## Optimizations + +Maglev performs a curated set of optimizations that are fast to execute: + +* **Inlining**: Small, hot functions can be inlined. +* **Type Guarding**: Inserts checks to ensure speculated types are correct at runtime, deoptimizing if they fail. +* **Smi Untagging/Retagging**: Optimizes operations on small integers by removing and restoring the Smi tag only when necessary. + +## Placement in the Pipeline + +Maglev sits between Sparkplug and the optimizing compilers (TurboFan and Turboshaft). It is triggered when a function becomes hot enough, but before it is deemed worthy of the full optimization power (and compilation time) of TurboFan or Turboshaft. + +## Turbolev + +In the new Turboshaft pipeline, Maglev can also be used as a frontend. In this mode (known as **Turbolev**, enabled with `--turbolev`), Maglev builds the graph and performs initial optimizations, which is then lowered into Turboshaft IR for further optimization and code generation. This allows reusing Maglev's fast graph building and speculatively optimized IR as a starting point for Turboshaft. + +## See Also +- [Why V8 Embraced CFG](../why-cfg.md) +- [Ignition](../../interpreter/interpreter-ignition.md) +- [Sparkplug](../sparkplug/compiler-sparkplug.md) +- [Hidden Classes and Inline Caches](../../runtime/hidden-classes-and-ics.md) diff --git a/deps/v8/docs/compiler/sparkplug/compiler-sparkplug.md b/deps/v8/docs/compiler/sparkplug/compiler-sparkplug.md new file mode 100644 index 00000000000000..01f3fe73f4d71f --- /dev/null +++ b/deps/v8/docs/compiler/sparkplug/compiler-sparkplug.md @@ -0,0 +1,58 @@ +# Sparkplug: V8's Baseline Compiler + +Sparkplug is V8's baseline compiler, introduced to fill the performance gap between the Ignition interpreter and the highly-optimizing TurboFan compiler. + +## Motivation + +While V8's Ignition interpreter is highly optimized, interpreters have inherent overheads such as bytecode decoding and dispatch. On the other hand, the TurboFan optimizing compiler can generate highly optimized code, but it requires time to run and needs stable type feedback to be effective. + +Sparkplug fills this gap by providing a fast compiler that generates machine code quickly, allowing for aggressive tier-up without waiting for stable feedback. + +## Architecture + +Sparkplug is a **non-optimizing compiler** that compiles Ignition bytecode directly into machine code. + +* **Compiles from Bytecode**: Sparkplug "cheats" by not compiling directly from JavaScript source. Instead, it uses the bytecode generated by the Ignition compiler. This means it doesn't have to worry about variable resolution, desugaring, or other complex parsing tasks. +* **No Intermediate Representation (IR)**: Sparkplug does not build an AST or a control flow graph. It iterates over the bytecode and generates machine code on the fly in a single linear pass. The compiler is essentially a switch statement inside a loop, dispatching to fixed per-bytecode machine code generation functions. +* **No Register Allocation**: It does not perform complex register allocation. Instead, it mirrors the register state of the Ignition interpreter. Virtual registers mapped to the stack in Ignition remain on the stack in Sparkplug-generated code. The accumulator register is mapped to a physical register. +* **Architecture Dependent**: Because there is no intermediate architecture-independent stage (due to the lack of IR), the entire implementation must be ported separately to each supported architecture. However, because the compiler is simple, this is relatively easy. + + +## Compilation Process + +The `BaselineCompiler` (defined in `src/baseline/baseline-compiler.h`) drives the compilation: + +1. It iterates through the `BytecodeArray` using a `BytecodeArrayIterator`. +2. For each bytecode, it dispatches to a specific visitor method (e.g., `VisitAdd`, `VisitStar`). +3. The visitor methods use a `BaselineAssembler` to emit the corresponding machine code instructions. + +## Interpreter-Compatible Frames + +Sparkplug maintains stack frames that are compatible with the Ignition interpreter. This design choice simplifies many aspects of integrating a new compiler: + +* **Frame Layout**: The stack frame layout for a Sparkplug-compiled function is identical to that of an interpreted function. Whenever the interpreter would have stored a register value, Sparkplug stores one too. +* **Seamless Integration**: Because Sparkplug frames look like interpreter frames, the debugger, profiler, exception stack unwinding, and stack trace printing continue to work with almost no changes. +* **Trivial On-Stack Replacement (OSR)**: Swapping between the interpreter and Sparkplug code can be done with almost zero frame translation overhead. +* **Bytecode Offset Mapping**: Sparkplug does not keep the bytecode offset up-to-date during execution. Instead, it maintains a two-way mapping between Sparkplug code address ranges and corresponding bytecode offsets. This mapping is used when the stack walker needs to know the bytecode offset. +* **FeedbackCell Caching**: The stack slot that would normally hold the bytecode offset in an interpreter frame is repurposed to cache the `FeedbackCell` for the currently executing function. (The `FeedbackVector` is also available in the frame, as in interpreter frames). + + +## Deferring to Builtins + +Sparkplug actually generates very little of its own code for complex operations. JavaScript semantics are complex, and regenerating this code inline would increase compile times and memory consumption. + +Instead, Sparkplug code mostly calls into "builtins" (small snippets of machine code embedded in the binary) to do the work. These builtins are often the same ones used by the interpreter or share most of their code with the interpreter's bytecode handlers. Sparkplug code is essentially a sequence of builtin calls and control flow. + +## Benefits + +* **Interpretation Overhead Removal**: Sparkplug removes unremovable interpreter overheads like operand decoding and next-bytecode dispatch. +* **Quick Startup**: It provides a performance boost very quickly after startup, before TurboFan has time to compile the code. + +## File Structure +* `src/baseline/`: Core Sparkplug implementation. +* `src/baseline/baseline-compiler.cc`: Contains the main compiler loop and bytecode visitors. +* `src/baseline/baseline-assembler.h`: Provides an abstraction over the macro-assembler for Sparkplug. + +## See Also +- [Ignition](../../interpreter/interpreter-ignition.md) +- [Function Architecture](../../runtime/function-architecture.md) diff --git a/deps/v8/docs/compiler/turbofan/compiler-turbofan.md b/deps/v8/docs/compiler/turbofan/compiler-turbofan.md new file mode 100644 index 00000000000000..373f0088e21687 --- /dev/null +++ b/deps/v8/docs/compiler/turbofan/compiler-turbofan.md @@ -0,0 +1,97 @@ +# TurboFan: V8's Optimizing Compiler + +TurboFan is V8's top-tier optimizing compiler. It is responsible for generating the most efficient machine code possible for hot functions, utilizing all available type information and aggressive optimization techniques. + +## Architecture + +TurboFan has historically used a **"Sea of Nodes"** Intermediate Representation (IR). V8 has transitioned to a new IR framework called **Turboshaft**, which is now enabled by default for JavaScript. The current pipeline often uses a hybrid approach, starting with Sea of Nodes and lowering to Turboshaft for later phases. + +### Sea of Nodes IR +In the Sea of Nodes representation, there is no strict control flow graph (CFG) during the early and middle optimization phases. Instead: +* **Nodes** represent operations (e.g., additions, loads, constants). +* **Edges** represent data flow, effect flow (ordering of operations with side effects), and control flow. +* This representation allows the compiler to freely reorder operations as long as data and effect dependencies are respected, enabling powerful optimizations like code motion and redundant load elimination. + +### Turboshaft +Turboshaft is the next-generation IR for V8. It uses a more structured control flow graph with basic blocks and linear sequences of operations within blocks. This makes certain optimizations easier to implement and reason about compared to the Sea of Nodes. + +## The Compilation Pipeline + +The compilation process is managed by the `Pipeline` class (defined in `src/compiler/pipeline.h`) and `turboshaft::Pipeline` (defined in `src/compiler/turboshaft/pipelines.h`). It consists of several phases, often spanning both IRs: + +1. **Graph Building**: The initial graph is built from Ignition bytecode or from Maglev IR in the Sea of Nodes representation. +2. **Sea of Nodes Optimizations**: The graph goes through a series of optimization phases in the Sea of Nodes IR, including: + * **Inlining**: Replacing function calls with the body of the called function. + * **Escape Analysis**: Determining if objects allocated in the function escape to the heap. + * **Simplified Lowering**: Lowering high-level JavaScript operations to simpler machine-level operations based on type feedback. + * **Loop Peeling**: Peeling loops to enable further optimizations. +3. **Turboshaft Conversion**: The optimized Sea of Nodes graph is converted to the Turboshaft IR. +4. **Turboshaft Optimizations**: Further optimizations are performed in Turboshaft, such as: + * **Machine Lowering**: Lowering to machine-level operations. + * **Load Elimination**: Removing redundant loads. + * **Loop Unrolling**: Unrolling loops for better performance. +5. **Instruction Selection**: Mapping the IR nodes to specific machine instructions for the target architecture. +6. **Register Allocation**: Assigning physical registers to virtual registers. +7. **Code Generation**: Emitting the final machine code. + +## Deoptimization + +TurboFan generates highly specialized code based on optimistic assumptions (e.g., assuming a specific hidden class). To ensure correctness, it inserts **checks** before specialized operations. + +If a check fails at runtime (e.g., a function receives an object with a Map it hasn't seen before), the code cannot continue. TurboFan triggers a **Deoptimization (Deopt)**. + +* The current state of the optimized frame is translated back into an unoptimized frame compatible with Ignition or Sparkplug. +* Execution resumes in the unoptimized tier. +* The `FeedbackVector` is updated to reflect the new reality, so that a future re-optimization can take it into account. + +## External Resources + +### Articles and blog posts + +- [A tale of TurboFan](https://benediktmeurer.de/2017/03/01/v8-behind-the-scenes-february-edition) +- [Ignition + TurboFan and ES2015](https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-november-edition) +- [An introduction to speculative optimization in V8](https://ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8) +- [Sea of Nodes](https://darksi.de/d.sea-of-nodes/) (External blog post) +- [High-level overview of TurboFan](/blog/turbofan-jit) (V8 blog post) + +### Talks + +- [CodeStubAssembler: Redux](https://docs.google.com/presentation/d/1u6bsgRBqyVY3RddMfF1ZaJ1hWmqHZiVMuPRw_iKpHlY) +- [An overview of the TurboFan compiler](https://docs.google.com/presentation/d/1H1lLsbclvzyOF3IUR05ZUaZcqDxo7_-8f4yJoxdMooU/edit) +- [TurboFan IR](https://docs.google.com/presentation/d/1Z9iIHojKDrXvZ27gRX51UxHD-bKf1QcPzSijntpMJBM) +- [TurboFan’s JIT Design](https://docs.google.com/presentation/d/1sOEF4MlF7LeO7uq-uThJSulJlTh--wgLeaVibsbb3tc) +- [Fast arithmetic for dynamic languages](https://docs.google.com/a/google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y) +- [Deoptimization in V8](https://docs.google.com/presentation/d/1Z6oCocRASCfTqGq1GCo1jbULDGS-w-nzxkbVF7Up0u0) +- [TurboFan: a new code generation architecture for V8](https://docs.google.com/presentation/d/1_eLlVzcj94_G4r9j9d_Lj5HRKFnq6jgpuPJtnmIBs88) ([video](https://www.youtube.com/watch?v=M1FBosB5tjM)) +- [An internship on laziness](https://docs.google.com/presentation/d/1AVu1wiz6Deyz1MDlhzOWZDRn6g_iFkcqsGce1F23i-M) (+ [blog post](/blog/lazy-unlinking)) + +### Design documents + +These are design documents that are mostly concerned with TurboFan internals. + +- [Function context specialization](https://docs.google.com/document/d/1CJbBtqzKmQxM1Mo4xU0ENA7KXqb1YzI6HQU8qESZ9Ic) +- [Rest parameters and arguments exotic objects optimization plan](https://docs.google.com/document/d/1DvDx3Xursn1ViV5k4rT4KB8HBfBb2GdUy3wzNfJWcKM) +- [TurboFan developer tools integration](https://docs.google.com/document/d/1zl0IA7dbPffvPPkaCmLVPttq4BYIfAe2Qy8sapkYgRE) +- [TurboFan inlining](https://docs.google.com/document/d/1l-oZOW3uU4kSAHccaMuUMl_RCwuQC526s0hcNVeAM1E) +- [TurboFan inlining heuristics](https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8) +- [TurboFan redundant bounds and overflow check elimination](https://docs.google.com/document/d/1R7-BIUnIKFzqki0jR4SfEZb3XmLafa04DLDrqhxgZ9U) +- [Lazy deoptimization without code patching](https://docs.google.com/document/d/1ELgd71B6iBaU6UmZ_lvwxf_OrYYnv0e4nuzZpK05-pg) +- [Register allocator](https://docs.google.com/document/d/1aeUugkWCF1biPB4tTZ2KT3mmRSDV785yWZhwzlJe5xY) +- [Projection nodes in TurboFan](https://docs.google.com/document/d/1C9P8T98P1T_r2ymuUFz2jFWLUL7gbb6FnAaRjabuOMY/edit) + +### Related design documents + +These are design documents that also affect TurboFan in a significant way. + +- [Computed property names (re)design document](https://docs.google.com/document/d/1eH1R6_C3lRrLtXKw0jNqAsqJ3cBecrqqvfRzLpfq7VE) +- [ES2015 and beyond performance plan](https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY) +- [Iterator builtins design document](https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8) +- [Making ES2015 classes fast](https://docs.google.com/document/d/1iCdbXuGVV8BK750wmP32eF4sCrnZ8y3Qlz0JiaLh9j8) +- [RegExp builtins (re)design document](https://docs.google.com/document/d/1MuqFjsfaRPL2ZqzVoeMRqtcAmcJSwmHljTbRIctVVUk) +- [Spread call performance](https://docs.google.com/document/d/1DWPizOSKqHhSJ7bdEI0HIVnner84xToEKUYqgXm3g30) + +## See Also +- [Ignition](../../interpreter/interpreter-ignition.md) +- [Sparkplug](../sparkplug/compiler-sparkplug.md) +- [Maglev](../maglev/compiler-maglev.md) +- [Hidden Classes and Inline Caches](../../runtime/hidden-classes-and-ics.md) diff --git a/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-copying-approach.md b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-copying-approach.md new file mode 100644 index 00000000000000..9b170f2788014e --- /dev/null +++ b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-copying-approach.md @@ -0,0 +1,49 @@ +# Turboshaft's Copying Approach: Semi-Spaces for IR + +This document explains a core design philosophy of the Turboshaft compiler: using a copying approach for graph transformations instead of in-place mutation. + +## The Core Philosophy: Copies are Cheap + +In traditional compilers, optimization passes often mutate the Intermediate Representation (IR) graph in-place. While this avoids copying overhead, it introduces significant complexity: +* **Complex Bookkeeping**: In-place mutation requires carefully updating def-use chains, invalidating and recomputing analyses, and handling node replacement safely. +* **Brittleness**: It is easy to leave the graph in an inconsistent state or violate invariants during complex transformations. + +Turboshaft takes the opposite approach. It assumes that **graph copies are cheap** and that the graph changes so much between phases that a full copy is often more efficient and much simpler to implement. + +## The "Semi-Spaces" Model + +Similar to a semi-space garbage collector, a typical Turboshaft phase operates on two graphs: +1. **Input Graph**: The read-only source graph for the phase. +2. **Output Graph**: A brand new graph being constructed by the phase. + +This approach is primarily implemented by `CopyingPhase` and `GraphVisitor` (see `src/compiler/turboshaft/copying-phase.h`). + +A phase iterates linearly through the blocks and operations of the input graph. As it processes each operation, it uses the **Reducer Stack** to determine what should be emitted into the output graph. The output graph then becomes the input graph for the next phase (often achieved by swapping the graphs, see `Graph::SwapWithCompanion` in `src/compiler/turboshaft/graph.h`). + +## Why is Copying Cheap in Turboshaft? + +Turboshaft's IR was designed from the ground up to make this copying approach viable and fast: + +### 1. Contiguous Memory Layout +Unlike Sea-of-Nodes (used in TurboFan), which uses a network of pointers between nodes scattered in memory, Turboshaft stores operations in a contiguous buffer called `OperationBuffer` (see `src/compiler/turboshaft/graph.h`). +* Operations are allocated sequentially in a zone. +* Iterating over the graph is a simple, cache-friendly linear scan of memory. + +### 2. Compact Representation +Operations are compact. References to other operations are not pointers but small integer offsets (`OpIndex`). This keeps the memory footprint small, making full graph copies fit well within CPU caches. + +### 3. Fast Allocation +Emitting an operation into the output graph is typically just an append operation to the end of the `OperationBuffer`, involving a few pointer increments and a store. + +## Advantages of the Copying Approach + +* **Simplicity**: Reducers only need to worry about generating the *correct new code*, not fixing up old code or maintaining complex graph invariants. +* **Immutability**: The input graph is immutable during a phase, making it safe to query without worrying about concurrent modifications or invalidation of analysis results. +* **Natural Dead Code Elimination**: If an operation in the input graph is not needed (e.g., it was simplified away or determined to be unreachable), the reducer simply refrains from emitting anything to the output graph. It naturally disappears. + +--- + +## See Also +- [Turboshaft Reducers](compiler-turboshaft-reducers.md): How reducers compose to transform the graph during copying. +- `src/compiler/turboshaft/graph.h`: Definition of `Graph` and `OperationBuffer`. +- `src/compiler/turboshaft/copying-phase.h`: Implementation of the copying phase driver. diff --git a/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-ir.md b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-ir.md new file mode 100644 index 00000000000000..d30501bc98e890 --- /dev/null +++ b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-ir.md @@ -0,0 +1,87 @@ +# Turboshaft IR Details + +This document dives into the details of Turboshaft's Intermediate Representation (IR), focusing on operation definitions and the side-effect system. + +## Overview + +Turboshaft is V8's next-generation optimizing compiler. Unlike its predecessor, TurboFan, which used a "Sea-of-Nodes" IR where control and data flow were intermingled, Turboshaft uses a more traditional **Control Flow Graph (CFG)** representation. + +In Turboshaft: +* The graph consists of **Blocks**. +* Each block contains a linear sequence of **Operations**. +* Control flow is explicit at the end of blocks (e.g., `Goto`, `Branch`, `Switch`). + +## Operation Definition + +Operations are defined in `src/compiler/turboshaft/operations.h`. Each operation is represented by a C++ `struct` (e.g., `WordBinopOp`, `LoadOp`) and has a corresponding `Opcode`. + +### Operation Categories +Turboshaft categorizes operations into several lists: +* **Machine Operations**: Low-level operations that map closely to machine instructions (e.g., `WordBinop`, `FloatBinop`, `Load`, `Store`). +* **Simplified Operations**: Higher-level operations that are lowered to machine operations (e.g., `CheckedClosure`, `CheckMaps`). +* **JS Operations**: Operations representing JavaScript semantics (e.g., `GenericBinop`). +* **Wasm Operations**: WebAssembly-specific operations. + +### Defining a New Operation +To define a new operation `Foo`: +1. Add `V(Foo)` to the appropriate operation list macro (e.g., `TURBOSHAFT_MACHINE_OPERATION_LIST`). +2. Define a `struct FooOp` deriving from `OperationT` or `FixedArityOperationT` (if it has fixed `N` inputs). +3. The struct should contain: + * Public fields for options. + * A getter `options()` returning a tuple of these options (used for printing and hashing), or custom `PrintOptions` and `hash_value`. + * Getters for named inputs. + * A constructor taking inputs first and then options. + * `outputs_rep()` and `inputs_rep()` methods defining representations. + * `OpEffects` as a static `effects` member or non-static `Effects()` method. +4. If the operation is not lowered before instruction selection, handle it in `instruction-selector.cc`. + +## The Side-Effect System + +One of Turboshaft's most innovative features is its fine-grained side-effect system, which enables safe and aggressive operation reordering. + +Instead of explicit effect chains (like in TurboFan), Turboshaft uses a **Produces/Consumes** model based on bitmasks. + +### Effect Dimensions +Defined in `EffectDimensions` (within `operations.h`), these are the individual bits of side effects: +* `load_heap_memory`: Reading from the JS heap. +* `store_heap_memory`: Writing to the JS heap. +* `load_off_heap_memory`: Reading from C++ memory or external resources. +* `store_off_heap_memory`: Writing to C++ memory or external resources. +* `control_flow`: Operation affects control flow (branches, throws, deopts). +* `before_raw_heap_access` / `after_raw_heap_access`: Used to ensure consistency during raw heap operations (like inline allocation) where the heap might be temporarily invalid. + +### OpEffects +Each operation defines its `OpEffects`, which consists of: +1. **Produces**: An `EffectDimensions` bitmask of what effects this operation generates. +2. **Consumes**: An `EffectDimensions` bitmask of what effects this operation depends on. +3. **Other properties**: + * `can_create_identity`: True if operation produces a fresh identity (e.g., allocation). Prevents GVN and moving in/out of loops. + * `can_allocate`: True if operation can trigger GC. + * `required_when_unused`: True if operation should not be removed even if its result is unused (e.g., stores, side-effecting ops). + +### Reordering Rules +Two operations **cannot** be reordered if the first operation **produces** an effect dimension that the second operation **consumes**. + +**Example**: +* `StoreOp` produces `store_heap_memory` and consumes `store_heap_memory` and `load_heap_memory`. +* `LoadOp` produces `load_heap_memory` and consumes `store_heap_memory`. + +If we have: +1. `StoreOp(addr1, val)` (Produces `store_heap_memory`) +2. `LoadOp(addr2)` (Consumes `store_heap_memory`) + +They cannot be reordered because operation 1 produces an effect that operation 2 consumes. + +However, if we have two loads: +1. `LoadOp(addr1)` (Produces `load_heap_memory`, Consumes `store_heap_memory`) +2. `LoadOp(addr2)` (Produces `load_heap_memory`, Consumes `store_heap_memory`) + +Neither produces an effect that the other consumes (they both produce `load`, but consume `store`). Thus, they can be freely reordered. + +This system allows Turboshaft to be very generous with reorderings when operations are high-level and pure, while automatically becoming more restrictive as operations are lowered to low-level memory accesses. + +--- + +## See Also +- `src/compiler/turboshaft/operations.h`: The source of truth for operations and effects. +- [Turboshaft](compiler-turboshaft.md): Overview of the Turboshaft pipeline. diff --git a/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-reducers.md b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-reducers.md new file mode 100644 index 00000000000000..66891393a83bf9 --- /dev/null +++ b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft-reducers.md @@ -0,0 +1,85 @@ +# Turboshaft Reducers: Composable Optimizations + +This document explains the Reducer architecture in Turboshaft, which allows for highly composable and efficient optimization passes. + +## The Reducer Pattern + +Unlike traditional compilers that often have separate phases for each optimization (each iterating over the graph), Turboshaft uses a stack of **Reducers**. + +A reducer is a component that intercepts the creation of IR operations. When an operation is being processed (e.g., during graph building or a copying phase), it passes through the stack of reducers. Each reducer has the opportunity to: +1. **Modify** the operation (e.g., simplify it). +2. **Replace** it with a different operation or a constant. +3. **Ignore** it and pass it to the next reducer in the stack. + +## Composing Phases + +Reducers are composed using C++ templates (CRTP and variadic templates). A phase is defined by a specific list of reducers. + +For example, a phase might be defined as: +```cpp +CopyingPhase< + DeadCodeEliminationReducer, + BranchEliminationReducer, + MachineLoweringReducer +>::Run(data, zone); +``` + +This creates a stack where `DeadCodeEliminationReducer` is at the top, and `MachineLoweringReducer` is near the bottom. + +## How a Reducer Works + +A reducer is a template class that takes `Next` as a template parameter and inherits from it. This forms the stack. + +> [!NOTE] +> The example below is simplified. In the actual V8 codebase, operations are often more generic (e.g., `WordBinop` instead of `Int32Add`) and take additional parameters like operation kind and representation. + +```cpp +template +class MyReducer : public Next { + public: + // Intercept the reduction of a WordBinop operation + OpIndex ReduceWordBinop(OpIndex left, OpIndex right, WordBinopOp::Kind kind, WordRepresentation rep) { + // Try to simplify or optimize (e.g., x + 0 => x) + if (kind == WordBinopOp::Kind::kAdd && IsConstantZero(right)) return left; + + // If we can't optimize, pass it to the next reducer in the stack + return Next::ReduceWordBinop(left, right, kind, rep); + } +}; +``` + +### Key Concepts + +* **`Next::Reduce[OpName]`**: Calls the next reducer in the stack. If no reducer overrides it, it eventually reaches the bottom of the stack where the operation is actually emitted into the output graph. +* **`Asm()`**: A helper to access the full assembler interface, allowing a reducer to emit new operations if needed. + +## The Copying Phase + +Many Turboshaft phases are **Copying Phases**. They iterate over an existing "input graph" and use the reducer stack to build a new "output graph". + +In `src/compiler/turboshaft/copying-phase.h`, `VisitOpNoMappingUpdate` uses a large switch statement to call `Asm().ReduceInputGraph[OpName]`: + +```cpp +#define EMIT_INSTR_CASE(Name) \ + case Opcode::k##Name: \ + if (MayThrow(Opcode::k##Name)) return OpIndex::Invalid(); \ + new_index = Asm().ReduceInputGraph##Name(index, op.Cast()); \ + break; +``` + +Note that operations that may throw are handled separately and not directly reduced here. + +This triggers the reducer stack for that operation. + +## Benefits of the Reducer Architecture + +* **Single Pass**: Multiple optimizations can be performed in a single pass over the graph, reducing memory traffic and increasing speed. +* **Modularity**: Each optimization is self-contained in a reducer and can be easily tested and reused in different phases. +* **Flexibility**: It is easy to add, remove, or reorder optimizations by changing the template arguments of a phase. + +--- + +## See Also +- `src/compiler/turboshaft/reducer-traits.h`: Metaprogramming for reducers. +- `src/compiler/turboshaft/copying-phase.h`: Implementation of the copying phase. +- [Turboshaft](compiler-turboshaft.md): Overview of Turboshaft. diff --git a/deps/v8/docs/compiler/turboshaft/compiler-turboshaft.md b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft.md new file mode 100644 index 00000000000000..ce635e3d9fafdc --- /dev/null +++ b/deps/v8/docs/compiler/turboshaft/compiler-turboshaft.md @@ -0,0 +1,78 @@ +# Turboshaft and Turbolev + +This document covers V8's next-generation optimizing compiler pipeline, **Turboshaft**, and its frontend for Maglev graphs, **Turbolev**. + +## Turboshaft: Next-Generation IR and Pipeline + +Turboshaft is designed to replace the Sea-of-Nodes IR used in TurboFan. It introduces a more traditional Control Flow Graph (CFG) representation with explicit blocks and instructions. + +### Key Features of Turboshaft +* **CFG-Based IR**: Unlike TurboFan's Sea-of-Nodes, where control and data flow are intermingled, Turboshaft uses a clear separation. Blocks contain a linear sequence of operations. +* **Reducers**: Optimizations are implemented as "Reducers" that can be composed. This makes it easier to write and combine optimization passes. +* **Performance**: Designed to be faster to compile and generate better code than TurboFan. + +### Common Reducers +Turboshaft includes many reducers for different optimization passes. Some examples include: +* **MachineOptimizationReducer**: Performs low-level machine-specific optimizations. +* **ValueNumberingReducer**: Implements global value numbering to eliminate redundant computations. +* **TypeInferenceReducer**: Infers types for operations to enable further optimizations. +* **BranchEliminationReducer**: Eliminates redundant branches based on known conditions. +* **LoopUnrollingReducer**: Unrolls loops to reduce overhead. + +## Motivation: Leaving the Sea of Nodes + +Turboshaft was created to address several pain points with TurboFan's Sea-of-Nodes IR: + +1. **Complexity**: Sea-of-Nodes graphs are hard to read and reason about. Effect and control chains must be managed manually, leading to subtle bugs. +2. **Limited Benefits for JS**: In JavaScript, most operations can have side effects or throw, meaning they must be on the effect or control chain. This defeats the purpose of Sea-of-Nodes, where operations are supposed to float freely. +3. **Slow Compilation**: Finding a good order to visit nodes for optimizations is hard in a soup of nodes, leading to many revisits. Cache locality is also poor because nodes are mutated in place and new nodes are allocated arbitrarily. +4. **Difficult Transformations**: Introducing new control flow during lowerings is hard because you have to figure out where to plug it into the control chain. + +Turboshaft's return to a CFG IR solves these issues, resulting in simpler code and significantly faster compilation times. + +For a more detailed discussion on why V8 adopted CFG and the benefits it brings, see [Why V8 Embraced CFG](../why-cfg.md). + +--- + +## Turbolev: Bridging Maglev and Turboshaft + +**Turbolev** (implemented in `src/compiler/turboshaft/turbolev-graph-builder.cc`) is a frontend for Turboshaft that constructs a Turboshaft graph directly from a **Maglev graph**. + +### Rationale +Maglev is fast to compile and collects good type feedback, building a graph that is already somewhat optimized and has environment/frame state information attached. By starting from the Maglev graph instead of starting over from bytecode, Turboshaft can: +1. Leverage the analysis and type inference already done by Maglev. +2. Save time on graph building. + +### Complex Graph Transformations + +Translating from Maglev to Turboshaft is not always a 1-to-1 mapping because they have different IR constraints. + +#### Example: Generator Resumes and Loop Dominance +A prime example of non-trivial translation is how Turbolev handles **Generators** (yield/resume). + +* **Maglev Constraint**: Maglev graphs for resumable generator functions can have edges that bypass loop headers (e.g., jumping directly into the middle of a loop from the initial switch-resume table). +* **Turboshaft Constraint**: In Turboshaft, a loop header must strictly dominate every block in the loop. It does not allow arbitrary edges bypassing the loop header. +* **Solution in Turbolev**: The `GeneratorAnalyzer` in `turbolev-graph-builder.cc` detects these loop header bypasses in the Maglev graph. Turbolev then transforms the graph by re-routing these resume edges to the loop headers and inserting secondary switches inside the loop to dispatch to the correct resume point. + +## Turboshaft Pipeline + +The general pipeline from IR to machine code in Turboshaft is as follows: + +1. **Graph Building**: The graph is built either from Ignition bytecode or by lowering from a higher-level representation (like Maglev via Turbolev). +2. **Optimization Phases**: The graph passes through multiple reducer phases (dead code elimination, loop unrolling, machine optimization, etc.). This usually involves copying the graph from an input to an output graph while applying optimizations on the fly. +3. **Scheduling**: The blocks are ordered, often using a special Reverse Post-Order (RPO) to ensure contiguous loop bodies. +4. **Instruction Selection**: The `InstructionSelector` visits the operations and emits corresponding machine instructions into an `InstructionSequence`. +5. **Register Allocation**: Registers are allocated for the values in the `InstructionSequence`. +6. **Code Generation**: The finalized instruction sequence is translated into the actual machine code (bytes) for the target architecture. + +## Instruction Selection + +Instruction Selection is the phase that bridges the high-level Turboshaft IR to the low-level machine instructions. + +* **Shared Backend**: Turboshaft leverages the existing backend infrastructure used by TurboFan. +* **Mapping to Instructions**: In `src/compiler/turboshaft/instruction-selection-phase.cc`, Turboshaft initializes an `InstructionSelector` specifically for Turboshaft graphs (`InstructionSelector::ForTurboshaft`). This selector traverses the Turboshaft IR and generates an `InstructionSequence`, mapping Turboshaft operations to architecture-specific machine instructions (defined in shared files like `instruction-selector-x64.cc`). + +## File Structure +* `src/compiler/turboshaft/`: Core Turboshaft implementation. +* `src/compiler/turboshaft/turbolev-graph-builder.cc`: The main implementation of the Maglev-to-Turboshaft translator. +* `src/compiler/turboshaft/turbolev-frontend-pipeline.cc`: The pipeline stages for the Turbolev frontend. diff --git a/deps/v8/docs/compiler/why-cfg.md b/deps/v8/docs/compiler/why-cfg.md new file mode 100644 index 00000000000000..87a1895e12cb6f --- /dev/null +++ b/deps/v8/docs/compiler/why-cfg.md @@ -0,0 +1,63 @@ +# Why V8 Embraced CFG (Control-Flow Graph) in Maglev and Turboshaft + +This document explains the technical reasons and benefits of using a traditional Control-Flow Graph (CFG) in V8's modern optimizing compilers, Maglev and Turboshaft, moving away from the Sea of Nodes (SoN) representation used in TurboFan. + +## Historical Context: The Sea of Nodes Era + +For many years, V8's TurboFan compiler used a **Sea of Nodes** (SoN) intermediate representation. In a Sea of Nodes, instructions are not bound to basic blocks; instead, they float freely based only on their true data, effect, and control dependencies. + +The promise of Sea of Nodes was that by relaxing the schedule until the very end of the pipeline, the compiler could find better global optimizations. It was a powerful approach that allowed TurboFan to overcome the limitations of its predecessor, Crankshaft. + +However, as the codebase grew and JavaScript evolved, the V8 team found that the Sea of Nodes approach introduced significant complexity and overhead that often outweighed its benefits for JavaScript workloads. + +For a detailed account of the transition, see the v8.dev blog post [Land ahoy: leaving the Sea of Nodes](https://v8.dev/blog/leaving-the-sea-of-nodes). + +## The Shift to CFG in Maglev and Turboshaft + +With the development of **Maglev** (V8's mid-tier compiler) and **Turboshaft** (V8's top-tier compiler), V8 returned to a more traditional **Control-Flow Graph** (CFG) representation, but with modern design choices that address the shortcomings of past architectures. + +Here is why CFG is the right choice for V8's current and future needs, applying to both tiers: + +### 1. Explicit Control Flow Fits JavaScript Better + +JavaScript is a highly dynamic language with frequent side effects, exceptions, and complex control flow. In a Sea of Nodes, representing these constraints requires complex chains of effect and control edges. + +In a CFG, control flow is explicit. Basic blocks define a clear execution order. This makes it much easier for both Maglev and Turboshaft to: +- Reason about side effects and dependencies. +- Implement optimizations that rely on control flow structure (like loop optimizations). +- Avoid subtle bugs related to manual chain management in lowerings. + +### 2. Faster Compilation and Support for Linear Passes + +A key goal for both compilers is compilation speed. CFG naturally supports fast, linear-scan algorithms. + +- **Linear Passes**: CFG allows for efficient linear-scan style optimizations and register allocation, avoiding the need to repeatedly visit nodes in a non-linear graph. Both Maglev and Turboshaft use linear scan register allocation, which is much simpler on a CFG. +- **Maglev's Direct Generation**: Maglev builds its graph in a single pass and generates code directly by iterating over blocks and nodes, avoiding complex scheduling phases. +- **Turboshaft's Copying Approach**: Turboshaft uses a copying phase approach rather than in-place mutation. This keeps nodes ordered linearly in memory, significantly reducing cache misses. + +### 3. Improved Developer Velocity and Readability + +A "sea of nodes" can quickly become a "soup of nodes," making it incredibly difficult for compiler engineers to inspect, debug, and understand the graph. This applies to any compiler tier. + +A CFG is much more intuitive. It resembles standard code structure with blocks and branches, making it easier for developers of both Maglev and Turboshaft to: +- Visualize the graph in tools like Turbolizer. +- Debug optimization passes. +- Onboard new engineers to the compiler team. + +### 4. Powerful and Predictable Optimizations + +While Sea of Nodes promised global optimizations, in practice, it often made certain optimizations harder. + +- **Loop Optimizations**: In a CFG, loop headers and bodies are explicitly defined, making loop peeling, unrolling, and invariant code motion much more straightforward. +- **Predictable Scheduling**: In Sea of Nodes, scheduling (assigning nodes to blocks) happened late and could sometimes produce unpredictable results or float operations too high. In a CFG, the schedule is maintained throughout, leading to more predictable behavior. + +## Conclusion + +The move to CFG in Maglev and Turboshaft is not a step backward, but a step forward. By adopting a structured CFG representation, V8 achieves massive improvements in compilation speed, codebase maintainability, and predictable optimizations across its modern optimizing compiler tiers. + +--- + +## See Also +- [Turboshaft](turboshaft/compiler-turboshaft.md): Overview of the Turboshaft compiler. +- [Turboshaft Copying Approach](turboshaft/compiler-turboshaft-copying-approach.md): Details on Turboshaft's semi-space IR. +- [Land ahoy: leaving the Sea of Nodes](https://v8.dev/blog/leaving-the-sea-of-nodes) on v8.dev. diff --git a/deps/v8/docs/contribute.md b/deps/v8/docs/contribute.md new file mode 100644 index 00000000000000..0c718866b01c73 --- /dev/null +++ b/deps/v8/docs/contribute.md @@ -0,0 +1,41 @@ +--- +title: 'Contributing to V8' +description: 'This document explains how to contribute to V8.' +--- +The information on this page explains how to contribute to V8. Be sure to read the whole thing before sending us a contribution. + +## Get the code + +See [Checking out the V8 source code](/docs/source-code). + +## Before you contribute + +### Ask on V8’s mailing list for guidance + +Before you start working on a larger V8 contribution, you should get in touch with us first through [the V8 contributor mailing list](https://groups.google.com/group/v8-dev) so we can help out and possibly guide you. Coordinating up front makes it much easier to avoid frustration later on. + +### Sign the CLA + +Before we can use your code you have to sign the [Google Individual Contributor License Agreement](https://cla.developers.google.com/about/google-individual), which you can do online. This is mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things, for instance that you’ll tell us if you know that your code infringes on other people’s patents. You don’t have to do this until after you’ve submitted your code for review and a member has approved it, but you will have to do it before we can put your code into our codebase. + +Contributions made by corporations are covered by a different agreement than the one above, the [Software Grant and Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate). + +Sign them online [here](https://cla.developers.google.com/). + +## Submit your code + +The source code of V8 follows the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) so you should familiarize yourself with those guidelines. Before submitting code you must pass all our [tests](/docs/test), and have to successfully run the presubmit checks: + +```bash +git cl presubmit +``` + +The presubmit script uses a linter from Google, [`cpplint.py`](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py). It is part of [`depot_tools`](https://dev.chromium.org/developers/how-tos/install-depot-tools), and it must be in your `PATH` — so if you have `depot_tools` in your `PATH`, everything should just work. + +### Upload to V8’s codereview tool + +All submissions, including submissions by project members, require review. We use the same code-review tools and process as the Chromium project. In order to submit a patch, you need to get the [`depot_tools`](https://dev.chromium.org/developers/how-tos/install-depot-tools) and follow these instructions on [requesting a review](https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md) (using your V8 workspace instead of a Chromium workspace). + +### Look out for breakage or regressions + +Once you have codereview approval, you can land your patch using the commit queue. It runs a bunch of tests and commits your patch if all tests pass. Once your change is committed, it is a good idea to watch [the console](https://ci.chromium.org/p/v8/g/main/console) until the bots turn green after your change, because the console runs a few more tests than the commit queue. diff --git a/deps/v8/docs/cross-compile-arm.md b/deps/v8/docs/cross-compile-arm.md new file mode 100644 index 00000000000000..f5d0622b97bda5 --- /dev/null +++ b/deps/v8/docs/cross-compile-arm.md @@ -0,0 +1,170 @@ +--- +title: 'Cross-compiling and debugging for ARM/Android' +description: 'This document explains how to cross-compile V8 for ARM/Android, and how to debug it.' +--- +First, make sure you can [build with GN](/docs/build-gn). + +Then, add `android` to your `.gclient` configuration file. + +```python +target_os = ['android'] # Add this to get Android stuff checked out. +``` + +The `target_os` field is a list, so if you're also building on unix it'll look like this: + +```python +target_os = ['android', 'unix'] # Multiple target OSes. +``` + +Run `gclient sync`, and you’ll get a large checkout under `./third_party/android_tools`. + +Enable developer mode on your phone or tablet, and turn on USB debugging, via instructions [here](https://developer.android.com/studio/run/device.html). Also, get the handy [`adb`](https://developer.android.com/studio/command-line/adb.html) tool on your path. It’s in your checkout at `./third_party/android_sdk/public/platform-tools`. + +## Using `gm` + +Use [the `tools/dev/gm.py` script](/docs/build-gn#gm) to automatically build V8 tests and run them on the device. + +```bash +alias gm=/path/to/v8/tools/dev/gm.py +gm android_arm.release.check +``` + +This command pushes the binaries and tests to the `/data/local/tmp/v8` directory on the device. + +## Manual build + +Use `v8gen.py` to generate an ARM release or debug build: + +```bash +tools/dev/v8gen.py arm.release +``` + +Then run `gn args out.gn/arm.release` and make sure you have the following keys: + +```python +target_os = "android" # These lines need to be changed manually +target_cpu = "arm" # as v8gen.py assumes a simulator build. +v8_target_cpu = "arm" +is_component_build = false +``` + +The keys should be the same for debug builds. If you are building for an arm64 device like the Pixel C, which supports 32bit and 64bit binaries, the keys should look like this: + +```python +target_os = "android" # These lines need to be changed manually +target_cpu = "arm64" # as v8gen.py assumes a simulator build. +v8_target_cpu = "arm64" +is_component_build = false +``` + +Now build: + +```bash +ninja -C out.gn/arm.release d8 +``` + +Use `adb` to copy the binary and snapshot files to the phone: + +```bash +adb shell 'mkdir -p /data/local/tmp/v8/bin' +adb push out.gn/arm.release/d8 /data/local/tmp/v8/bin +adb push out.gn/arm.release/icudtl.dat /data/local/tmp/v8/bin +adb push out.gn/arm.release/snapshot_blob.bin /data/local/tmp/v8/bin +``` + +```bash +rebuffat:~/src/v8$ adb shell +bullhead:/ $ cd /data/local/tmp/v8/bin +bullhead:/data/local/tmp/v8/bin $ ls +v8 icudtl.dat snapshot_blob.bin +bullhead:/data/local/tmp/v8/bin $ ./d8 +V8 version 5.8.0 (candidate) +d8> 'w00t!' +"w00t!" +d8> +``` + +## Debugging + +### d8 + +Remote debugging `d8` on an Android device is relatively simple. First start `gdbserver` on the Android device: + +```bash +bullhead:/data/local/tmp/v8/bin $ gdbserver :5039 $D8 +``` + +Then connect to the server on your host device. + +```bash +adb forward tcp:5039 tcp:5039 +gdb $D8 +gdb> target remote :5039 +``` + +`gdb` and `gdbserver` need to be compatible with each other, if in doubt use the binaries from the [Android NDK](https://developer.android.com/ndk). Note that by default the `d8` binary is stripped (debugging info removed), `$OUT_DIR/exe.unstripped/d8` contains the unstripped binary though. + +### Logging + +By default, some of `d8`’s debugging output ends up in the Android system log, which can be dumped using [`logcat`](https://developer.android.com/studio/command-line/logcat). Unfortunately, sometimes part of a particular debugging output is split between system log and `adb`, and sometimes some part seems to be completely missing. To avoid these issues, it is recommended to add the following setting to the `gn args`: + +```python +v8_android_log_stdout = true +``` + +### Floating-point issues + +The `gn args` setting `arm_float_abi = "hard"`, which is used by the V8 Arm GC Stress bot, can result in completely nonsensical program behavior on hardware different from the one the GC stress bot is using (e.g. on Nexus 7). + +## Using Sourcery G++ Lite + +The Sourcery G++ Lite cross compiler suite is a free version of Sourcery G++ from [CodeSourcery](http://www.codesourcery.com/). There is a page for the [GNU Toolchain for ARM Processors](http://www.codesourcery.com/sgpp/lite/arm). Determine the version you need for your host/target combination. + +The following instructions use [2009q1-203 for ARM GNU/Linux](http://www.codesourcery.com/sgpp/lite/arm/portal/release858), and if using a different version please change the URLs and `TOOL_PREFIX` below accordingly. + +### Installing on host and target + +The simplest way of setting this up is to install the full Sourcery G++ Lite package on both the host and target at the same location. This will ensure that all the libraries required are available on both sides. If you want to use the default libraries on the host there is no need the install anything on the target. + +The following script installs in `/opt/codesourcery`: + +```bash +#!/bin/sh + +sudo mkdir /opt/codesourcery +cd /opt/codesourcery +sudo chown "$USERNAME" . +chmod g+ws . +umask 2 +wget http://www.codesourcery.com/sgpp/lite/arm/portal/package4571/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 +tar -xvf arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 +``` + +## Profile + +- Compile a binary, push it to the device, keep a copy of it on the host: + + ```bash + adb shell cp /data/local/tmp/v8/bin/d8 /data/local/tmp/v8/bin/d8-version.under.test + cp out.gn/arm.release/d8 ./d8-version.under.test + ``` + +- Get a profiling log and copy it to the host: + + ```bash + adb push benchmarks /data/local/tmp + adb shell cd /data/local/tmp/benchmarks; ../v8/bin/d8-version.under.test run.js --prof + adb shell /data/local/tmp/v8/bin/d8-version.under.test benchmark.js --prof + adb pull /data/local/tmp/benchmarks/v8.log ./ + ``` + +- Open `v8.log` in your favorite editor and edit the first line to match the full path of the `d8-version.under.test` binary on your workstation (instead of the `/data/local/tmp/v8/bin/` path it had on the device) + +- Run the tick processor with the host’s `d8` and an appropriate `nm` binary: + + ```bash + cp out/x64.release/d8 . # only required once + cp out/x64.release/natives_blob.bin . # only required once + cp out/x64.release/snapshot_blob.bin . # only required once + tools/linux-tick-processor --nm=$(pwd)/third_party/android_ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-nm + ``` diff --git a/deps/v8/docs/cross-compile-ios.md b/deps/v8/docs/cross-compile-ios.md new file mode 100644 index 00000000000000..6f7e8725955234 --- /dev/null +++ b/deps/v8/docs/cross-compile-ios.md @@ -0,0 +1,52 @@ +--- +title: 'Cross-compiling for iOS' +description: 'This document explains how to cross-compile V8 for iOS.' +--- +This page serves as a brief introduction to building V8 for iOS targets. + +## Requirements + +- A macOS (OS X) host machine with Xcode installed. +- A 64-bit target iOS device (legacy 32-bit iOS devices are unsupported). +- V8 v7.5 or newer. +- jitless is a hard requirement for iOS (as of Dec. 2020). Therefore please use the flags '--expose_gc --jitless' + +## Initial setup + +Follow [the instructions to build V8](/docs/build). + +Fetch additional tools needed for iOS cross-compilation by adding `target_os` in your `.gclient` configuration file, located in the parent directory of the `v8` source directory: + +```python +# [... other contents of .gclient such as the 'solutions' variable ...] +target_os = ['ios'] +``` + +After updating `.gclient`, run `gclient sync` to download the additional tools. + +## Manual build + +This section shows how to build a monolithic V8 version for use on either a physical iOS device or the Xcode iOS simulator. The output of this build is a `libv8_monolith.a` file that contains all V8 libraries as well as the V8 snapshot. + +Set up GN build files by running `gn args out/release-ios` and inserting the following keys: + +```python +ios_deployment_target = 10 +is_component_build = false +is_debug = false +target_cpu = "arm64" # "x64" for a simulator build. +target_os = "ios" +use_custom_libcxx = false # Use Xcode's libcxx. +v8_enable_i18n_support = false # Produces a smaller binary. +v8_monolithic = true # Enable the v8_monolith target. +v8_use_external_startup_data = false # The snapshot is included in the binary. +v8_enable_pointer_compression = false # Unsupported on iOS. +``` + +Now build: + +```bash +ninja -C out/release-ios v8_monolith +``` + +Finally, add the generated `libv8_monolith.a` file to your Xcode project as a static library. For further documentation on embedding V8 in your application, see [Getting started with embedding V8](/docs/embed). diff --git a/deps/v8/docs/d8.md b/deps/v8/docs/d8.md new file mode 100644 index 00000000000000..658bf782f1da09 --- /dev/null +++ b/deps/v8/docs/d8.md @@ -0,0 +1,80 @@ +--- +title: 'Using `d8`' +description: 'd8 is V8’s own developer shell.' +--- +[`d8`](https://crsrc.org/c/v8/src/d8/) is V8’s own developer shell. + +`d8` is useful for running some JavaScript locally or debugging changes you have made to V8. [Building V8 using GN](/docs/build-gn) for x64 outputs a `d8` binary in `out/x64.optdebug/d8`. You can call `d8` with the `--help` argument for more information about usage and flags. + +## Print to the command line + +Printing output is probably going to be very important if you plan to use `d8` to run JavaScript files rather than interactively. This can be achieved using `console.log`: + +```bash +$ cat test.js +console.log('Hello world!'); + +$ out/x64.optdebug/d8 test.js +Hello world! +``` + +`d8` also comes with a global `print` function that does the same thing. However, `console.log` is preferred over `print` since it works in web browsers as well. + +## Read input + +Using `read()` you can store the contents of a file into a variable. + +```js +d8> const license = read('LICENSE'); +d8> license +"This license applies to all parts of V8 that are not externally +maintained libraries. The externally maintained libraries used by V8 +are: +… (etc.)" +``` + +Use `readline()` to interactively enter text: + +```js +d8> const greeting = readline(); +Welcome +d8> greeting +"Welcome" +``` + +## Load external scripts + +`load()` runs another JavaScript file in the current context, meaning that you can then access anything declared in that file. + +```js +$ cat util.js +function greet(name) { + return 'Hello, ' + name; +} + +$ d8 +d8> load('util.js'); +d8> greet('World!'); +"Hello, World!" +``` + +## Pass flags into JavaScript + +It’s possible to make command-line arguments available to your JavaScript code at runtime with `d8`. Just pass them after `--` on the command line. You can then access them at the top-level of your script using the `arguments` object. + +```bash +out/x64.optdebug/d8 -- hi +``` + +You can now access an array of the arguments using the `arguments` object: + +```js +d8> arguments[0] +"hi" +``` + +## More resources + +[Kevin Ennis’s D8 Guide](https://gist.github.com/kevincennis/0cd2138c78a07412ef21) has really good information about exploring V8 using `d8`. + +Background of the name `d8`: very early on, V8 had a “[sample shell](https://crsrc.org/c/v8/samples/shell.cc)”, whose purpose was to demonstrate how V8 could be embedded to build a JavaScript shell. It was intentionally minimalist, and was simply called “shell”. Soon after, a “developer shell” was added with more convenience features to aid developers in their daily work, and it needed a name too. The original reason why “d8” was chosen as a name is lost to history; it caught on because “eveloper” is 8 omitted characters, so “d8 shell” makes sense as an abbreviation, and also fits in nicely with “V8” as the project name. diff --git a/deps/v8/docs/debug-arm.md b/deps/v8/docs/debug-arm.md new file mode 100644 index 00000000000000..748bf83b26e7cf --- /dev/null +++ b/deps/v8/docs/debug-arm.md @@ -0,0 +1,521 @@ +--- +title: 'Arm debugging with the simulator' +description: 'The Arm simulator and debugger can be very helpful when working with V8 code generation.' +--- +The simulator and debugger can be very helpful when working with V8 code generation. + +- It is convenient as it allows you to test code generation without access to actual hardware. +- No [cross](/docs/cross-compile-arm) or native compilation is needed. +- The simulator fully supports the debugging of generated code. + +Please note that this simulator is designed for V8 purposes. Only the features used by V8 are implemented, and you might encounter unimplemented features or instructions. In this case, feel free to implement them and submit the code! + +- [Compiling](#compiling) +- [Starting the debugger](#start_debug) +- [Debugging commands](#debug_commands) + - [printobject](#po) + - [trace](#trace) + - [break](#break) +- [Extra breakpoint features](#extra) + - [32-bit: `stop()`](#arm32_stop) + - [64-bit: `Debug()`](#arm64_debug) + +## Compiling for Arm using the simulator { #compiling } + +By default on an x86 host, compiling for Arm with [gm](/docs/build-gn#gm) will give you a simulator build: + +```bash +gm arm64.debug # For a 64-bit build or... +gm arm.debug # ... for a 32-bit build. +``` + +You may also build the `optdebug` configuration as the `debug` may be a little slow, especially if you want to run the V8 test suite. + +## Starting the debugger { #start_debug } + +You can start the debugger immediately from the command line after `n` instructions: + +```bash +out/arm64.debug/d8 --stop_sim_at # Or out/arm.debug/d8 for a 32-bit build. +``` + +Alternatively, you can generate a breakpoint instruction in the generated code: + +Natively, breakpoint instructions cause the program to halt with a `SIGTRAP` signal, allowing you to debug the issue with gdb. However, if running with a simulator, a breakpoint instruction in generated code will instead drop you into the simulator debugger. + +You can generate a breakpoint in multiple ways by using `DebugBreak()` from [Torque](/docs/torque-builtins), from the [CodeStubAssembler](/docs/csa-builtins), as a node in a [TurboFan](/docs/turbofan) pass, or directly using an assembler. + +Here we focus on debugging low-level native code, so let's look at the assembler method: + +```cpp +TurboAssembler::DebugBreak(); +``` + +Let's say we have a jitted function called `add` compiled with [TurboFan](/docs/turbofan) and we'd like to break at the start. Given a `test.js` example: + +{ #test.js } + +```js +// Our optimized function. +function add(a, b) { + return a + b; +} + +// Typical cheat code enabled by --allow-natives-syntax. +%PrepareFunctionForOptimization(add); + +// Give the optimizing compiler type feedback so it'll speculate `a` and `b` are +// numbers. +add(1, 3); + +// And force it to optimize. +%OptimizeFunctionOnNextCall(add); +add(5, 7); +``` + +To do it, we can hook into TurboFan's [code generator](https://crsrc.org/c/v8/src/compiler/backend/code-generator.cc?q=CodeGenerator::AssembleCode) and access the assembler to insert our breakpoint: + +```cpp +void CodeGenerator::AssembleCode() { + // ... + + // Check if we're optimizing, then look-up the name of the current function and + // insert a breakpoint. + if (info->IsOptimizing()) { + AllowHandleDereference allow_handle_dereference; + if (info->shared_info()->PassesFilter("add")) { + tasm()->DebugBreak(); + } + } + + // ... +} +``` + +And let's run it: + +```simulator +$ d8 \ + # Enable '%' cheat code JS functions. + --allow-natives-syntax \ + # Disassemble our function. + --print-opt-code --print-opt-code-filter="add" --code-comments \ + # Disable spectre mitigations for readability. + --no-untrusted-code-mitigations \ + test.js +--- Raw source --- +(a, b) { + return a + b; +} + + +--- Optimized code --- +optimization_id = 0 +source_position = 12 +kind = OPTIMIZED_FUNCTION +name = add +stack_slots = 6 +compiler = turbofan +address = 0x7f0900082ba1 + +Instructions (size = 504) +0x7f0900082be0 0 d45bd600 constant pool begin (num_const = 6) +0x7f0900082be4 4 00000000 constant +0x7f0900082be8 8 00000001 constant +0x7f0900082bec c 75626544 constant +0x7f0900082bf0 10 65724267 constant +0x7f0900082bf4 14 00006b61 constant +0x7f0900082bf8 18 d45bd7e0 constant + -- Prologue: check code start register -- +0x7f0900082bfc 1c 10ffff30 adr x16, #-0x1c (addr 0x7f0900082be0) +0x7f0900082c00 20 eb02021f cmp x16, x2 +0x7f0900082c04 24 54000080 b.eq #+0x10 (addr 0x7f0900082c14) + Abort message: + Wrong value in code start register passed +0x7f0900082c08 28 d2800d01 movz x1, #0x68 + -- Inlined Trampoline to Abort -- +0x7f0900082c0c 2c 58000d70 ldr x16, pc+428 (addr 0x00007f0900082db8) ;; off heap target +0x7f0900082c10 30 d63f0200 blr x16 + -- Prologue: check for deoptimization -- + [ DecompressTaggedPointer +0x7f0900082c14 34 b85d0050 ldur w16, [x2, #-48] +0x7f0900082c18 38 8b100350 add x16, x26, x16 + ] +0x7f0900082c1c 3c b8407210 ldur w16, [x16, #7] +0x7f0900082c20 40 36000070 tbz w16, #0, #+0xc (addr 0x7f0900082c2c) + -- Inlined Trampoline to CompileLazyDeoptimizedCode -- +0x7f0900082c24 44 58000c31 ldr x17, pc+388 (addr 0x00007f0900082da8) ;; off heap target +0x7f0900082c28 48 d61f0220 br x17 + -- B0 start (construct frame) -- +(...) + +--- End code --- +# Debugger hit 0: DebugBreak +0x00007f0900082bfc 10ffff30 adr x16, #-0x1c (addr 0x7f0900082be0) +sim> +``` + +We can see we've stopped at the start of the optimized function and the simulator gave us a prompt! + +Note this is just an example and V8 changes quickly so the details may vary. But you should be able to do this anywhere where an assembler is available. + +## Debugging commands { #debug_commands } + +### Common commands + +Enter `help` in the debugger prompt to get details on available commands. These include usual gdb-like commands, such as `stepi`, `cont`, `disasm`, etc. If the Simulator is run under gdb, the `gdb` debugger command will give control to gdb. You can then use `cont` from gdb to go back to the debugger. + +### Architecture specific commands + +Each target architecture implements its own simulator and debugger, so the experience and details will vary. + +- [printobject](#po) +- [trace](#trace) +- [break](#break) + +#### `printobject $register` (alias `po`) { #po } + +Describe a JS object held in a register. + +For example, let's say this time we're running [our example](#test.js) on a 32-bit Arm simulator build. We can examine incoming arguments passed in registers: + +```simulator +$ ./out/arm.debug/d8 --allow-natives-syntax test.js +Simulator hit stop, breaking at the next instruction: + 0x26842e24 e24fc00c sub ip, pc, #12 +sim> print r1 +r1: 0x4b60ffb1 1264648113 +# The current function object is passed with r1. +sim> printobject r1 +r1: +0x4b60ffb1: [Function] in OldSpace + - map: 0x485801f9 [FastProperties] + - prototype: 0x4b6010f1 + - elements: 0x5b700661 [HOLEY_ELEMENTS] + - function prototype: + - initial_map: + - shared_info: 0x4b60fe9d + - name: 0x5b701c5d + - formal_parameter_count: 2 + - kind: NormalFunction + - context: 0x4b600c65 + - code: 0x26842de1 + - source code: (a, b) { + return a + b; +} +(...) + +# Now print the current JS context passed in r7. +sim> printobject r7 +r7: +0x449c0c65: [NativeContext] in OldSpace + - map: 0x561000b9 + - length: 261 + - scope_info: 0x34081341 + - previous: 0 + - native_context: 0x449c0c65 + 0: 0x34081341 + 1: 0 + 2: 0x449cdaf5 + 3: 0x58480c25 + 4: 0x58485499 + 5: 0x561018a1 + 6: 0x3408027d + 7: 0x449c75c1 + 8: 0x561010f9 + 9: 0x449c967d + 10: 0x449c8dbd +(...) +``` + +#### `trace` (alias `t`) { #trace } + +Enable or disable tracing executed instructions. + +When enabled, the simulator will print disassembled instructions as it is executing them. If you're running a 64-bit Arm build, the simulator is also able to trace changes to register values. + +You may also enable this from the command-line with the `--trace-sim` flag to enable tracing from the start. + +With the same [example](#test.js): + +```simulator +$ out/arm64.debug/d8 --allow-natives-syntax \ + # --debug-sim is required on 64-bit Arm to enable disassembly + # when tracing. + --debug-sim test.js +# Debugger hit 0: DebugBreak +0x00007f1e00082bfc 10ffff30 adr x16, #-0x1c (addr 0x7f1e00082be0) +sim> trace +0x00007f1e00082bfc 10ffff30 adr x16, #-0x1c (addr 0x7f1e00082be0) +Enabling disassembly, registers and memory write tracing + +# Break on the return address stored in the lr register. +sim> break lr +Set a breakpoint at 0x7f1f880abd28 +0x00007f1e00082bfc 10ffff30 adr x16, #-0x1c (addr 0x7f1e00082be0) + +# Continuing will trace the function's execution until we return, allowing +# us to make sense of what is happening. +sim> continue +# x0: 0x00007f1e00082ba1 +# x1: 0x00007f1e08250125 +# x2: 0x00007f1e00082be0 +(...) + +# We first load the 'a' and 'b' arguments from the stack and check if they +# are tagged numbers. This is indicated by the least significant bit being 0. +0x00007f1e00082c90 f9401fe2 ldr x2, [sp, #56] +# x2: 0x000000000000000a <- 0x00007f1f821f0278 +0x00007f1e00082c94 7200005f tst w2, #0x1 +# NZCV: N:0 Z:1 C:0 V:0 +0x00007f1e00082c98 54000ac1 b.ne #+0x158 (addr 0x7f1e00082df0) +0x00007f1e00082c9c f9401be3 ldr x3, [sp, #48] +# x3: 0x000000000000000e <- 0x00007f1f821f0270 +0x00007f1e00082ca0 7200007f tst w3, #0x1 +# NZCV: N:0 Z:1 C:0 V:0 +0x00007f1e00082ca4 54000a81 b.ne #+0x150 (addr 0x7f1e00082df4) + +# Then we untag and add 'a' and 'b' together. +0x00007f1e00082ca8 13017c44 asr w4, w2, #1 +# x4: 0x0000000000000005 +0x00007f1e00082cac 2b830484 adds w4, w4, w3, asr #1 +# NZCV: N:0 Z:0 C:0 V:0 +# x4: 0x000000000000000c +# That's 5 + 7 == 12, all good! + +# Then we check for overflows and tag the result again. +0x00007f1e00082cb0 54000a46 b.vs #+0x148 (addr 0x7f1e00082df8) +0x00007f1e00082cb4 2b040082 adds w2, w4, w4 +# NZCV: N:0 Z:0 C:0 V:0 +# x2: 0x0000000000000018 +0x00007f1e00082cb8 54000466 b.vs #+0x8c (addr 0x7f1e00082d44) + + +# And finally we place the result in x0. +0x00007f1e00082cbc aa0203e0 mov x0, x2 +# x0: 0x0000000000000018 +(...) + +0x00007f1e00082cec d65f03c0 ret +Hit and disabled a breakpoint at 0x7f1f880abd28. +0x00007f1f880abd28 f85e83b4 ldur x20, [fp, #-24] +sim> +``` + +#### `break $address` { #break } + +Inserts a breakpoint at the specified address. + +Note that on 32-bit Arm, you can have only one breakpoint and you'll need to disable write protection on code pages to insert it. The 64-bit Arm simulator does not have such restrictions. + +With our [example](#test.js) again: + +```simulator +$ out/arm.debug/d8 --allow-natives-syntax \ + # This is useful to know which address to break to. + --print-opt-code --print-opt-code-filter="add" \ + test.js +(...) + +Simulator hit stop, breaking at the next instruction: + 0x488c2e20 e24fc00c sub ip, pc, #12 + +# Break on a known interesting address, where we start +# loading 'a' and 'b'. +sim> break 0x488c2e9c +sim> continue + 0x488c2e9c e59b200c ldr r2, [fp, #+12] + +# We can look-ahead with 'disasm'. +sim> disasm 10 + 0x488c2e9c e59b200c ldr r2, [fp, #+12] + 0x488c2ea0 e3120001 tst r2, #1 + 0x488c2ea4 1a000037 bne +228 -> 0x488c2f88 + 0x488c2ea8 e59b3008 ldr r3, [fp, #+8] + 0x488c2eac e3130001 tst r3, #1 + 0x488c2eb0 1a000037 bne +228 -> 0x488c2f94 + 0x488c2eb4 e1a040c2 mov r4, r2, asr #1 + 0x488c2eb8 e09440c3 adds r4, r4, r3, asr #1 + 0x488c2ebc 6a000037 bvs +228 -> 0x488c2fa0 + 0x488c2ec0 e0942004 adds r2, r4, r4 + +# And try and break on the result of the first `adds` instructions. +sim> break 0x488c2ebc +setting breakpoint failed + +# Ah, we need to delete the breakpoint first. +sim> del +sim> break 0x488c2ebc +sim> cont + 0x488c2ebc 6a000037 bvs +228 -> 0x488c2fa0 + +sim> print r4 +r4: 0x0000000c 12 +# That's 5 + 7 == 12, all good! +``` + +### Generated breakpoint instructions with a few additional features { #extra } + +Instead of `TurboAssembler::DebugBreak()`, you may use a lower-level instruction which has the same effect except with additional features. + +- [32-bit: `stop()`](#arm32_stop) +- [64-bit: `Debug()`](#arm64_debug) + +#### `stop()` (32-bit Arm) { #arm32_stop } + +```cpp +Assembler::stop(Condition cond = al, int32_t code = kDefaultStopCode); +``` + +The first argument is the condition and the second is the stop code. If a code is specified, and is less than 256, the stop is said to be “watched”, and can be disabled/enabled; a counter also keeps track of how many times the Simulator hits this code. + +Imagine we are working on this V8 C++ code: + +```cpp +__ stop(al, 123); +__ mov(r0, r0); +__ mov(r0, r0); +__ mov(r0, r0); +__ mov(r0, r0); +__ mov(r0, r0); +__ stop(al, 0x1); +__ mov(r1, r1); +__ mov(r1, r1); +__ mov(r1, r1); +__ mov(r1, r1); +__ mov(r1, r1); +``` + +Here's a sample debugging session: + +We hit the first stop. + +```simulator +Simulator hit stop 123, breaking at the next instruction: + 0xb53559e8 e1a00000 mov r0, r0 +``` + +We can see the following stop using `disasm`. + +```simulator +sim> disasm + 0xb53559e8 e1a00000 mov r0, r0 + 0xb53559ec e1a00000 mov r0, r0 + 0xb53559f0 e1a00000 mov r0, r0 + 0xb53559f4 e1a00000 mov r0, r0 + 0xb53559f8 e1a00000 mov r0, r0 + 0xb53559fc ef800001 stop 1 - 0x1 + 0xb5355a00 e1a00000 mov r1, r1 + 0xb5355a04 e1a00000 mov r1, r1 + 0xb5355a08 e1a00000 mov r1, r1 +``` + +Information can be printed for all (watched) stops which were hit at least once. + +```simulator +sim> stop info all +Stop information: +stop 123 - 0x7b: Enabled, counter = 1 +sim> cont +Simulator hit stop 1, breaking at the next instruction: + 0xb5355a04 e1a00000 mov r1, r1 +sim> stop info all +Stop information: +stop 1 - 0x1: Enabled, counter = 1 +stop 123 - 0x7b: Enabled, counter = 1 +``` + +Stops can be disabled or enabled. (Only available for watched stops.) + +```simulator +sim> stop disable 1 +sim> cont +Simulator hit stop 123, breaking at the next instruction: + 0xb5356808 e1a00000 mov r0, r0 +sim> cont +Simulator hit stop 123, breaking at the next instruction: + 0xb5356c28 e1a00000 mov r0, r0 +sim> stop info all +Stop information: +stop 1 - 0x1: Disabled, counter = 2 +stop 123 - 0x7b: Enabled, counter = 3 +sim> stop enable 1 +sim> cont +Simulator hit stop 1, breaking at the next instruction: + 0xb5356c44 e1a00000 mov r1, r1 +sim> stop disable all +sim> con +``` + +#### `Debug()` (64-bit Arm) { #arm64_debug } + +```cpp +MacroAssembler::Debug(const char* message, uint32_t code, Instr params = BREAK); +``` + +This instruction is a breakpoint by default, but is also able to enable and disable tracing as if you had done it with the [`trace`](#trace) command in the debugger. You can also give it a message and a code as an identifier. + +Imagine we are working on this V8 C++ code, taken from the native builtin that prepares the frame to call a JS function. + +```cpp +int64_t bad_frame_pointer = -1L; // Bad frame pointer, should fail if it is used. +__ Mov(x13, bad_frame_pointer); +__ Mov(x12, StackFrame::TypeToMarker(type)); +__ Mov(x11, ExternalReference::Create(IsolateAddressId::kCEntryFPAddress, + masm->isolate())); +__ Ldr(x10, MemOperand(x11)); + +__ Push(x13, x12, xzr, x10); +``` + +It might be useful to insert a breakpoint with `DebugBreak()` so we can examine the current state when we run this. But we can go further and trace this code if we use `Debug()` instead: + +```cpp +// Start tracing and log disassembly and register values. +__ Debug("start tracing", 42, TRACE_ENABLE | LOG_ALL); + +int64_t bad_frame_pointer = -1L; // Bad frame pointer, should fail if it is used. +__ Mov(x13, bad_frame_pointer); +__ Mov(x12, StackFrame::TypeToMarker(type)); +__ Mov(x11, ExternalReference::Create(IsolateAddressId::kCEntryFPAddress, + masm->isolate())); +__ Ldr(x10, MemOperand(x11)); + +__ Push(x13, x12, xzr, x10); + +// Stop tracing. +__ Debug("stop tracing", 42, TRACE_DISABLE); +``` + +It allows us to trace register values for __just__ the snippet of code we're working on: + +```simulator +$ d8 --allow-natives-syntax --debug-sim test.js +# NZCV: N:0 Z:0 C:0 V:0 +# FPCR: AHP:0 DN:0 FZ:0 RMode:0b00 (Round to Nearest) +# x0: 0x00007fbf00000000 +# x1: 0x00007fbf0804030d +# x2: 0x00007fbf082500e1 +(...) + +0x00007fc039d31cb0 9280000d movn x13, #0x0 +# x13: 0xffffffffffffffff +0x00007fc039d31cb4 d280004c movz x12, #0x2 +# x12: 0x0000000000000002 +0x00007fc039d31cb8 d2864110 movz x16, #0x3208 +# ip0: 0x0000000000003208 +0x00007fc039d31cbc 8b10034b add x11, x26, x16 +# x11: 0x00007fbf00003208 +0x00007fc039d31cc0 f940016a ldr x10, [x11] +# x10: 0x0000000000000000 <- 0x00007fbf00003208 +0x00007fc039d31cc4 a9be7fea stp x10, xzr, [sp, #-32]! +# sp: 0x00007fc033e81340 +# x10: 0x0000000000000000 -> 0x00007fc033e81340 +# xzr: 0x0000000000000000 -> 0x00007fc033e81348 +0x00007fc039d31cc8 a90137ec stp x12, x13, [sp, #16] +# x12: 0x0000000000000002 -> 0x00007fc033e81350 +# x13: 0xffffffffffffffff -> 0x00007fc033e81358 +0x00007fc039d31ccc 910063fd add fp, sp, #0x18 (24) +# fp: 0x00007fc033e81358 +0x00007fc039d31cd0 d45bd600 hlt #0xdeb0 +``` diff --git a/deps/v8/docs/design-review-guidelines.md b/deps/v8/docs/design-review-guidelines.md new file mode 100644 index 00000000000000..69ebd6b73c5f47 --- /dev/null +++ b/deps/v8/docs/design-review-guidelines.md @@ -0,0 +1,148 @@ +--- +title: 'Design review guidelines' +description: 'This document explains the V8 project’s design review guidelines.' +--- +Please make sure to follow the following guidelines when applicable. + +There are multiple drivers for the formalization of V8’s design reviews: + +1. make it clear to Individual Contributors (ICs) who the decision makers are and highlight what the path forward in the case that projects are not proceeding due to technical disagreement +1. create a forum to have straight-forward design discussions +1. ensure V8 Technical Leads (TL) are aware of all significant changes and have the opportunity to give their input on the Tech Lead (TL) layer +1. increase the involvement of all V8 contributors over the globe + +## Summary + +![V8’s Design Review Guidelines at a glance](/_img/docs/design-review-guidelines/design-review-guidelines.svg) + +Important: + +1. assume good intentions +1. be kind and civilized +1. be pragmatic + +The proposed solution is based on the following assumption/pillars: + +1. The proposed workflow puts the individual contributor (IC) in charge. They are the one who facilitate the process. +1. Their guiding TLs are tasked to help them navigate the territory and find the right LGTM providers. +1. If a feature is uncontroversial, nearly no overhead should be created. +1. If there is a lot of controversy, the feature can be 'escalated' to the V8 Eng Review Owners meeting where further steps are decided. + +## Roles + +### Individual Contributor (IC) + +LGTM: N/A +This person is the creator of the feature and the creator of the design documentation. + +### The Tech Lead (TL) of the IC + +LGTM: Must have +This person is the TL of a given project or component. Likely this is the person that is an owner of the main component your feature is going to touch. If it is not clear who the TL is, please ask the V8 Eng Review Owners via v8-eng-review-owners@googlegroups.com. TLs are responsible to add more people to the list of required LGTMs if appropriate. + +### LGTM provider + +LGTM: Must have +This is a person that is required to give LGTM. It might be an IC, or a TL(M). + +### “Random” reviewer of the document (RRotD) { #rrotd } + +LGTM: Not required +This is somebody who is simply reviewing and comment on the proposal. Their input should be considered, although their LGTM is not required. + +### V8 Eng Review Owners + +LGTM: Not required +Stuck proposals can be escalated to the V8 Eng Review Owners via . Potential use cases of such an escalation: + +- an LGTM provider is non-responsive +- no consensus on the design can be reached + +The V8 Eng Review Owners can overrule non-LGTMs or LGTMs. + +## Detailed workflow + +![V8’s Design Review Guidelines at a glance](/_img/docs/design-review-guidelines/design-review-guidelines.svg) + +1. Start: IC decides to work on a feature/gets a feature assigned to them +1. IC sends out their early design doc/explainer/one pager to a few RRotDs + 1. Prototypes are considered part of the "design doc" +1. IC adds people to the list of LGTM providers that the IC thinks should give their LGTM. The TL is a must have on the list of LGTM providers. +1. IC incorporates feedback. +1. TL adds more people to the list of LGTM providers. +1. IC sends out the early design doc/explainer/one pager to . +1. IC collects the LGTMs. TL helps them. + 1. LGTM provider reviews document, add comments and gives either an LGTM or not LGTM at the beginning of the document. If they add a not LGTM, they are obligated to list the reason(s). + 1. Optional: LGTM providers can remove themselves from the list of LGTM providers and/or suggest other LGTM providers + 1. IC and TL work to resolve the unresolved issues. + 1. If all LGTM are gathered send an email to v8-dev@googlegroups.com (e.g. by pinging the original thread) and announce implementation. +1. Optional: If IC and TL are blocked and/or want to have a broader discussion they can escalate the issue to the V8 Eng Review Owners. + 1. IC sends a mail to v8-eng-review-owners@googlegroups.com + 1. TL in CC + 1. Link to design doc in the mail + 1. Every V8 Eng Review Owners member is obligated to review the doc and optionally add themselves to the list of LGTM providers. + 1. Next steps to unblock the feature are decided. + 1. If the blocker is not resolved afterwards or new, unresolvable blockers are discovered, goto 8. +1. Optional: If "not LGTMs" are added after the feature was approved already, they should be treated like normal, unresolved issues. + 1. IC and TL work to resolve the unresolved issues. +1. End: IC proceeds with the feature. + +And always remember: + +1. assume good intentions +1. be kind and civilized +1. be pragmatic + +## FAQ + +### How to decide if the feature is worthy to have a design document? + +Some pointers when a design doc is appropriate: + +- Touches at least two components +- Needs reconciliation with non-V8 projects e.g. Debugger, Blink +- Take longer than 1 week of effort to implement +- Is a language feature +- Platform specific code will be touched +- User facing changes +- Has special security consideration or security impact is not obvious + +When in doubt, ask the TL. + +### How to decide who to add to the list of LGTM providers? + +Some pointers when people should be added to the list of LGTM providers: + +- OWNERs of the source files/directories you anticipate to touch +- Main component expert of the components you anticipate to touch +- Downstream consumers of your changes e.g. when you change an API + +### Who is “my” TL? + +Likely this is the person that is an owner of the main component your feature is going to touch. If it is not clear who the TL is, please ask the V8 Eng Review Owners via . + +### Where can I find a template for design documents? + +[Here](https://docs.google.com/document/d/1CWNKvxOYXGMHepW31hPwaFz9mOqffaXnuGqhMqcyFYo/template/preview). + +### What if something big changes? + +Make sure you still have the LGTMs e.g. by pinging the LGTM providers with a clear, reasonable deadline to veto. + +### LGTM providers don’t comment on my doc, what should I do? + +In this case you can follow this path of escalation: + +- Ping them directly via mail, Hangouts or comment/assignment in the doc and specifically ask them explicitly to add an LGTM or non-LGTM. +- Get your TL involved and ask them for help. +- Escalate to . + +### Somebody added me as an LGTM provider to a doc, what should I do? + +V8 is aiming to make decisions more transparent and escalation more straight-forward. If you think the design is good enough and should be done add an “LGTM” to the table cell next to your name. + +If you have blocking concerns or remarks, please add “Not LGTM, because \” into the table cell next to your name. Be prepared to get asked for another round of review. + +### How does this work together with the Blink Intents process? + +The V8 Design Review Guidelines complement [V8’s Blink Intent+Errata process](/docs/feature-launch-process). If you are launching a new WebAssembly or JavaScript language feature, please follow V8’s Blink Intent+Errata process and the V8 Design Review Guidelines. It likely makes sense to have all the LGTMs gathered at the point in time you would send an Intent to Implement. diff --git a/deps/v8/docs/embed.md b/deps/v8/docs/embed.md new file mode 100644 index 00000000000000..b756a954408cc3 --- /dev/null +++ b/deps/v8/docs/embed.md @@ -0,0 +1,438 @@ +--- +title: 'Getting started with embedding V8' +description: 'This document introduces some key V8 concepts and provides a “hello world” example to get you started with V8 code.' +--- +This document introduces some key V8 concepts and provides a “hello world” example to get you started with V8 code. + +## Audience + +This document is intended for C++ programmers who want to embed the V8 JavaScript engine within a C++ application. It helps you to make your own application’s C++ objects and methods available to JavaScript, and to make JavaScript objects and functions available to your C++ application. + +## Hello world + +Let’s look at a [Hello World example](https://crsrc.org/c/v8/samples/hello-world.cc) that takes a JavaScript statement as a string argument, executes it as JavaScript code, and prints the result to standard out. + +First, some key concepts: + +- An isolate is a VM instance with its own heap. +- A local handle is a pointer to an object. All V8 objects are accessed using handles. They are necessary because of the way the V8 garbage collector works. +- A handle scope can be thought of as a container for any number of handles. When you've finished with your handles, instead of deleting each one individually you can simply delete their scope. +- A context is an execution environment that allows separate, unrelated, JavaScript code to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run. + +These concepts are discussed in greater detail in [the advanced guide](/docs/embed#advanced-guide). + +## Run the example + +Follow the steps below to run the example yourself: + +1. Download the V8 source code by following [the Git instructions](/docs/source-code#using-git). +1. The instructions for this hello world example have last been tested with V8 v13.1. You can check out this branch with `git checkout branch-heads/13.1 -b sample -t` +1. Create a build configuration using the helper script: + + ```bash + tools/dev/gm.py x64.release.sample + ``` + + You can inspect and manually edit the build configuration by running: + + ```bash + gn args out/x64.release.sample + ``` + +1. Build the static library on a Linux 64 system: + + ```bash + ninja -C out/x64.release.sample v8_monolith + ``` + +1. Compile `hello-world.cc`, linking to the static library created in the build process. For example, on 64bit Linux using the GNU compiler and LLD linker: + + ```bash + g++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti -fuse-ld=lld -lv8_monolith -lv8_libbase -lv8_libplatform -ldl -Lout/x64.release.sample/obj/ -pthread -std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX + ``` + +1. For more complex code, V8 fails without an ICU data file. Copy this file to where your binary is stored: + + ```bash + cp out/x64.release.sample/icudtl.dat . + ``` + +1. Run the `hello_world` executable file at the command line. e.g. On Linux, in the V8 directory, run: + + ```bash + ./hello_world + ``` + +1. It prints `Hello, World!`. Yay! + Note: as of November 2024, it might also segfault early during process startup. Investigation is pending. If you run into this and can figure out what's wrong, please comment on [issue 377222400](https://issues.chromium.org/issues/377222400), or [submit a patch](https://v8.dev/docs/contribute). + +If you are looking for an example which is in sync with the main branch, check out the file [`hello-world.cc`](https://crsrc.org/c/v8/samples/hello-world.cc). This is a very simple example and you’ll likely want to do more than just execute scripts as strings. [The advanced guide below](#advanced-guide) contains more information for V8 embedders. + +## More example code + +The following samples are provided as part of the source code download. + +### [`process.cc`](https://crsrc.org/c/v8/samples/process.cc) + +This sample provides the code necessary to extend a hypothetical HTTP request processing application — which could be part of a web server, for example — so that it is scriptable. It takes a JavaScript script as an argument, which must provide a function called `Process`. The JavaScript `Process` function can be used to, for example, collect information such as how many hits each page served by the fictional web server gets. + +### [`shell.cc`](https://crsrc.org/c/v8/samples/shell.cc) + +This sample takes filenames as arguments then reads and executes their contents. Includes a command prompt at which you can enter JavaScript code snippets which are then executed. In this sample additional functions like `print` are also added to JavaScript through the use of object and function templates. + +## Advanced guide + +Now that you’re familiar with using V8 as a standalone virtual machine and with some key V8 concepts such as handles, scopes, and contexts, let’s discuss these concepts further and introduce a few other concepts that are key to embedding V8 within your own C++ application. + +The V8 API provides functions for compiling and executing scripts, accessing C++ methods and data structures, handling errors, and enabling security checks. Your application can use V8 just like any other C++ library. Your C++ code accesses V8 through the V8 API by including the header `include/v8.h`. + +### Handles and garbage collection + +A handle provides a reference to a JavaScript object’s location in the heap. The V8 garbage collector reclaims memory used by objects that can no longer again be accessed. During the garbage collection process the garbage collector often moves objects to different locations in the heap. When the garbage collector moves an object the garbage collector also updates all handles that refer to the object with the object’s new location. + +An object is considered garbage if it is inaccessible from JavaScript and there are no handles that refer to it. From time to time the garbage collector removes all objects considered to be garbage. V8’s garbage collection mechanism is key to V8’s performance. + +There are several types of handles: + +- Local handles are held on a stack and are deleted when the appropriate destructor is called. These handles’ lifetime is determined by a handle scope, which is often created at the beginning of a function call. When the handle scope is deleted, the garbage collector is free to deallocate those objects previously referenced by handles in the handle scope, provided they are no longer accessible from JavaScript or other handles. This type of handle is used in the hello world example above. + + Local handles have the class `Local`. + + **Note:** The handle stack is not part of the C++ call stack, but the handle scopes are embedded in the C++ stack. Handle scopes can only be stack-allocated, not allocated with `new`. + +- Persistent handles provide a reference to a heap-allocated JavaScript Object, just like a local handle. There are two flavors, which differ in the lifetime management of the reference they handle. Use a persistent handle when you need to keep a reference to an object for more than one function call, or when handle lifetimes do not correspond to C++ scopes. Google Chrome, for example, uses persistent handles to refer to Document Object Model (DOM) nodes. A persistent handle can be made weak, using `PersistentBase::SetWeak`, to trigger a callback from the garbage collector when the only references to an object are from weak persistent handles. + + - A `UniquePersistent` handle relies on C++ constructors and destructors to manage the lifetime of the underlying object. + - A `Persistent` can be constructed with its constructor, but must be explicitly cleared with `Persistent::Reset`. + +- There are other types of handles which are rarely used, that we will only briefly mention here: + + - `Eternal` is a persistent handle for JavaScript objects that are expected to never be deleted. It is cheaper to use because it relieves the garbage collector from determining the liveness of that object. + - Both `Persistent` and `UniquePersistent` cannot be copied, which makes them unsuitable as values with pre-C++11 standard library containers. `PersistentValueMap` and `PersistentValueVector` provide container classes for persistent values, with map and vector-like semantics. C++11 embedders do not require these, since C++11 move semantics solve the underlying problem. + +Of course, creating a local handle every time you create an object can result in a lot of handles! This is where handle scopes are very useful. You can think of a handle scope as a container that holds lots of handles. When the handle scope’s destructor is called all handles created within that scope are removed from the stack. As you would expect, this results in the objects to which the handles point being eligible for deletion from the heap by the garbage collector. + +Returning to [our very simple hello world example](#hello-world), in the following diagram you can see the handle-stack and heap-allocated objects. Note that `Context::New()` returns a `Local` handle, and we create a new `Persistent` handle based on it to demonstrate the usage of `Persistent` handles. + +![](/_img/docs/embed/local-persist-handles-review.png) + +When the destructor `HandleScope::~HandleScope` is called, the handle scope is deleted. Objects referred to by handles within the deleted handle scope are eligible for removal in the next garbage collection if there are no other references to them. The garbage collector can also remove the `source_obj`, and `script_obj` objects from the heap as they are no longer referenced by any handles or otherwise reachable from JavaScript. Since the context handle is a persistent handle, it is not removed when the handle scope is exited. The only way to remove the context handle is to explicitly call `Reset` on it. + +:::note +**Note:** Throughout this document the term “handle” refers to a local handle. When discussing a persistent handle, that term is used in full. +::: + +It is important to be aware of one common pitfall with this model: *you cannot return a local handle directly from a function that declares a handle scope*. If you do the local handle you’re trying to return will end up being deleted by the handle scope’s destructor immediately before the function returns. The proper way to return a local handle is construct an `EscapableHandleScope` instead of a `HandleScope` and to call the `Escape` method on the handle scope, passing in the handle whose value you want to return. Here’s an example of how that works in practice: + +```cpp +// This function returns a new array with three elements, x, y, and z. +Local NewPointArray(int x, int y, int z) { + v8::Isolate* isolate = v8::Isolate::GetCurrent(); + + // We will be creating temporary handles so we use a handle scope. + v8::EscapableHandleScope handle_scope(isolate); + + // Create a new empty array. + v8::Local array = v8::Array::New(isolate, 3); + + // Return an empty result if there was an error creating the array. + if (array.IsEmpty()) + return v8::Local(); + + Local context = isolate->GetCurrentContext(); + + // Fill out the values + array->Set(context, 0, v8::Integer::New(isolate, x)).Check(); + array->Set(context, 1, v8::Integer::New(isolate, y)).Check(); + array->Set(context, 2, v8::Integer::New(isolate, z)).Check(); + + // Return the value through Escape. + return handle_scope.Escape(array); +} +``` + +The `Escape` method copies the value of its argument into the enclosing scope, deletes all its local handles, and then gives back the new handle copy which can safely be returned. + +### Contexts + +In V8, a context is an execution environment that allows separate, unrelated, JavaScript applications to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run. + +Why is this necessary? Because JavaScript provides a set of built-in utility functions and objects that can be changed by JavaScript code. For example, if two entirely unrelated JavaScript functions both changed the global object in the same way then unexpected results are fairly likely to happen. + +In terms of CPU time and memory, it might seem an expensive operation to create a new execution context given the number of built-in objects that must be built. However, V8’s extensive caching ensures that, while the first context you create is somewhat expensive, subsequent contexts are much cheaper. This is because the first context needs to create the built-in objects and parse the built-in JavaScript code while subsequent contexts only have to create the built-in objects for their context. With the V8 snapshot feature (activated with build option `snapshot=yes`, which is the default) the time spent creating the first context will be highly optimized as a snapshot includes a serialized heap which contains already compiled code for the built-in JavaScript code. Along with garbage collection, V8’s extensive caching is also key to V8’s performance. + +When you have created a context you can enter and exit it any number of times. While you are in context A you can also enter a different context, B, which means that you replace A as the current context with B. When you exit B then A is restored as the current context. This is illustrated below: + +![](/_img/docs/embed/intro-contexts.png) + +Note that the built-in utility functions and objects of each context are kept separate. You can optionally set a security token when you create a context. See the [Security Model](#security-model) section for more information. + +The motivation for using contexts in V8 was so that each window and iframe in a browser can have its own fresh JavaScript environment. + +### Templates + +A template is a blueprint for JavaScript functions and objects in a context. You can use a template to wrap C++ functions and data structures within JavaScript objects so that they can be manipulated by JavaScript scripts. For example, Google Chrome uses templates to wrap C++ DOM nodes as JavaScript objects and to install functions in the global namespace. You can create a set of templates and then use the same ones for every new context you make. You can have as many templates as you require. However you can only have one instance of any template in any given context. + +In JavaScript there is a strong duality between functions and objects. To create a new type of object in Java or C++ you would typically define a new class. In JavaScript you create a new function instead, and create instances using the function as a constructor. The layout and functionality of a JavaScript object is closely tied to the function that constructed it. This is reflected in the way V8 templates work. There are two types of templates: + +- Function templates + + A function template is the blueprint for a single function. You create a JavaScript instance of the template by calling the template’s `GetFunction` method from within the context in which you wish to instantiate the JavaScript function. You can also associate a C++ callback with a function template which is called when the JavaScript function instance is invoked. + +- Object templates + + Each function template has an associated object template. This is used to configure objects created with this function as their constructor. You can associate two types of C++ callbacks with object templates: + + - accessor callbacks are invoked when a specific object property is accessed by a script + - interceptor callbacks are invoked when any object property is accessed by a script + + [Accessors](#accessors) and [interceptors](#interceptors) are discussed later in this document. + +The following code provides an example of creating a template for the global object and setting the built-in global functions. + +```cpp +// Create a template for the global object and set the +// built-in global functions. +v8::Local global = v8::ObjectTemplate::New(isolate); +global->Set(v8::String::NewFromUtf8Literal(isolate, "log"), + v8::FunctionTemplate::New(isolate, LogCallback)); + +// Each processor gets its own context so different processors +// do not affect each other. +v8::Local context = + v8::Context::New(isolate, nullptr, global); +``` + +This example code is taken from `JsHttpProcessor::Initializer` in the `process.cc` sample. + +### Accessors + +An accessor is a C++ callback that calculates and returns a value when an object property is accessed by a JavaScript script. Accessors are configured through an object template, using the `SetAccessor` method. This method takes the name of the property with which it is associated and two callbacks to run when a script attempts to read or write the property. + +The complexity of an accessor depends upon the type of data you are manipulating: + +- [Accessing static global variables](#accessing-static-global-variables) +- [Accessing dynamic variables](#accessing-dynamic-variables) + +### Accessing static global variables + +Let’s say there are two C++ integer variables, `x` and `y` that are to be made available to JavaScript as global variables within a context. To do this, you need to call C++ accessor functions whenever a script reads or writes those variables. These accessor functions convert a C++ integer to a JavaScript integer using `v8::Integer::New`, and convert a JavaScript integer to a C++ integer using `Int32Value`. An example is provided below: + +```cpp +void XGetter(v8::Local property, + const v8::PropertyCallbackInfo& info) { + info.GetReturnValue().Set(x); +} + +void XSetter(v8::Local property, v8::Local value, + const v8::PropertyCallbackInfo& info) { + v8::Local context = info.GetIsolate()->GetCurrentContext(); + x = value->Int32Value(context).ToChecked(); +} + +// YGetter/YSetter are so similar they are omitted for brevity + +v8::Local global_templ = v8::ObjectTemplate::New(isolate); +global_templ->SetAccessor(v8::String::NewFromUtf8Literal(isolate, "x"), + XGetter, XSetter); +global_templ->SetAccessor(v8::String::NewFromUtf8Literal(isolate, "y"), + YGetter, YSetter); +v8::Local context = + v8::Context::New(isolate, nullptr, global_templ); +``` + +Note that the object template in the code above is created at the same time as the context. The template could have been created in advance and then used for any number of contexts. + +### Accessing dynamic variables + +In the preceding example the variables were static and global. What if the data being manipulated is dynamic, as is true of the DOM tree in a browser? Let’s imagine `x` and `y` are object fields on the C++ class `Point`: + +```cpp +class Point { + public: + Point(int x, int y) : x_(x), y_(y) { } + int x_, y_; +} +``` + +To make any number of C++ `point` instances available to JavaScript we need to create one JavaScript object for each C++ `point` and make a connection between the JavaScript object and the C++ instance. This is done with external values and internal object fields. + +First create an object template for the `point` wrapper object: + +```cpp +v8::Local point_templ = v8::ObjectTemplate::New(isolate); +``` + +Each JavaScript `point` object keeps a reference to the C++ object for which it is a wrapper with an internal field. These fields are so named because they cannot be accessed from within JavaScript, they can only be accessed from C++ code. An object can have any number of internal fields, the number of internal fields is set on the object template as follows: + +```cpp +point_templ->SetInternalFieldCount(1); +``` + +Here the internal field count is set to `1` which means the object has one internal field, with an index of `0`, that points to a C++ object. + +Add the `x` and `y` accessors to the template: + +```cpp +point_templ->SetAccessor(v8::String::NewFromUtf8Literal(isolate, "x"), + GetPointX, SetPointX); +point_templ->SetAccessor(v8::String::NewFromUtf8Literal(isolate, "y"), + GetPointY, SetPointY); +``` + +Next, wrap a C++ point by creating a new instance of the template and then setting the internal field `0` to an external wrapper around the point `p`. + +```cpp +Point* p = ...; +v8::Local context = isolate->GetCurrentContext(); +v8::Local obj = point_templ->NewInstance(context).ToLocalChecked(); +obj->SetInternalField(0, v8::External::New(isolate, p)); +``` + +The external object is simply a wrapper around a `void*`. External objects can only be used to store reference values in internal fields. JavaScript objects can not have references to C++ objects directly so the external value is used as a "bridge" to go from JavaScript into C++. In that sense external values are the opposite of handles since handles lets C++ make references to JavaScript objects. + +Here’s the definition of the `get` and `set` accessors for `x`, the `y` accessor definitions are identical except `y` replaces `x`: + +```cpp +void GetPointX(v8::Local property, + const v8::PropertyCallbackInfo& info) { + v8::Local self = info.Holder(); + v8::Local wrap = + v8::Local::Cast(self->GetInternalField(0)); + void* ptr = wrap->Value(); + int value = static_cast(ptr)->x_; + info.GetReturnValue().Set(value); +} + +void SetPointX(v8::Local property, v8::Local value, + const v8::PropertyCallbackInfo& info) { + v8::Local self = info.Holder(); + v8::Local wrap = + v8::Local::Cast(self->GetInternalField(0)); + void* ptr = wrap->Value(); + v8::Local context = info.GetIsolate()->GetCurrentContext(); + static_cast(ptr)->x_ = value->Int32Value(context).ToChecked(); +} +``` + +Accessors extract the reference to the `point` object that was wrapped by the JavaScript object and then read and writes the associated field. This way these generic accessors can be used on any number of wrapped point objects. + +### Interceptors + +You can also specify a callback for whenever a script accesses any object property. These are called interceptors. For efficiency, there are two types of interceptors: + +- *named property interceptors* - called when accessing properties with string names. + An example of this, in a browser environment, is `document.theFormName.elementName`. +- *indexed property interceptors* - called when accessing indexed properties. An example of this, in a browser environment, is `document.forms.elements[0]`. + +The sample `process.cc`, provided with the V8 source code, includes an example of using interceptors. In the following code snippet `SetNamedPropertyHandler` specifies the `MapGet` and `MapSet` interceptors: + +```cpp +v8::Local result = v8::ObjectTemplate::New(isolate); +result->SetNamedPropertyHandler(MapGet, MapSet); +``` + +The `MapGet` interceptor is provided below: + +```cpp +void JsHttpRequestProcessor::MapGet(v8::Local name, + const v8::PropertyCallbackInfo& info) { + // Fetch the map wrapped by this object. + map *obj = UnwrapMap(info.Holder()); + + // Convert the JavaScript string to a std::string. + string key = ObjectToString(name); + + // Look up the value if it exists using the standard STL idiom. + map::iterator iter = obj->find(key); + + // If the key is not present return an empty handle as signal. + if (iter == obj->end()) return; + + // Otherwise fetch the value and wrap it in a JavaScript string. + const string &value = (*iter).second; + info.GetReturnValue().Set(v8::String::NewFromUtf8( + info.GetIsolate(), value.c_str(), v8::NewStringType::kNormal, + static_cast(value.length())).ToLocalChecked()); +} +``` + +As with accessors, the specified callbacks are invoked whenever a property is accessed. The difference between accessors and interceptors is that interceptors handle all properties, while accessors are associated with one specific property. + +### Security model + +The “same-origin policy” (first introduced with Netscape Navigator 2.0) prevents a document or script loaded from one “origin” from getting or setting properties of a document from a different “origin”. The term origin is defined here as a combination of domain name (e.g. `www.example.com`), protocol (e.g. `https`) and port. For example, `www.example.com:81` is not the same origin as `www.example.com`. All three must match for two web pages to be considered to have the same origin. Without this protection, a malicious web page could compromise the integrity of another web page. + +In V8 an “origin” is defined as a context. Access to any context other than the one from which you are calling is not allowed by default. To access a context other than the one from which you are calling, you need to use security tokens or security callbacks. A security token can be any value but is typically a symbol, a canonical string that does not exist anywhere else. You can optionally specify a security token with `SetSecurityToken` when you set up a context. If you do not specify a security token V8 will automatically generate one for the context you are creating. + +When an attempt is made to access a global variable the V8 security system first checks the security token of the global object being accessed against the security token of the code attempting to access the global object. If the tokens match access is granted. If the tokens do not match V8 performs a callback to check if access should be allowed. You can specify whether access to an object should be allowed by setting the security callback on the object, using the `SetAccessCheckCallbacks` method on object templates. The V8 security system can then fetch the security callback of the object being accessed and call it to ask if another context is allowed to access it. This callback is given the object being accessed, the name of the property being accessed, the type of access (read, write, or delete for example) and returns whether or not to allow access. + +This mechanism is implemented in Google Chrome so that if security tokens do not match, a special callback is used to allow access only to the following: `window.focus()`, `window.blur()`, `window.close()`, `window.location`, `window.open()`, `history.forward()`, `history.back()`, and `history.go()`. + +### Exceptions + +V8 throws an exception if an error occurs — for example, when a script or function attempts to read a property that does not exist, or if a function is called that is not a function. + +V8 returns an empty handle if an operation did not succeed. It is therefore important that your code checks a return value is not an empty handle before continuing execution. Check for an empty handle with the `Local` class’s public member function `IsEmpty()`. + +You can catch exceptions with `TryCatch`, for example: + +```cpp +v8::TryCatch trycatch(isolate); +v8::Local context = isolate->GetCurrentContext(); +v8::Local v; +if (!script->Run(context).ToLocal(&v)) { + v8::Local exception = trycatch.Exception(); + v8::String::Utf8Value exception_str(isolate, exception); + printf("Exception: %s\n", *exception_str); + // ... +} +``` + +If the value returned is an empty handle, and you do not have a `TryCatch` in place, your code must bail out. If you do have a `TryCatch` the exception is caught and your code is allowed to continue processing. + +### Inheritance + +JavaScript is a *class-free*, object-oriented language, and as such, it uses prototypal inheritance instead of classical inheritance. This can be puzzling to programmers trained in conventional object-oriented languages like C++ and Java. + +Class-based object-oriented languages, such as Java and C++, are founded on the concept of two distinct entities: classes and instances. JavaScript is a prototype-based language and so does not make this distinction: it simply has objects. JavaScript does not natively support the declaration of class hierarchies; however, JavaScript’s prototype mechanism simplifies the process of adding custom properties and methods to all instances of an object. In JavaScript, you can add custom properties to objects. For example: + +```js +// Create an object named `bicycle`. +function bicycle() {} +// Create an instance of `bicycle` called `roadbike`. +var roadbike = new bicycle(); +// Define a custom property, `wheels`, on `roadbike`. +roadbike.wheels = 2; +``` + +A custom property added this way only exists for that instance of the object. If we create another instance of `bicycle()`, called `mountainbike` for example, `mountainbike.wheels` would return `undefined` unless the `wheels` property is explicitly added. + +Sometimes this is exactly what is required, at other times it would be helpful to add the custom property to all instances of an object - all bicycles have wheels after all. This is where the prototype object of JavaScript is very useful. To use the prototype object, reference the keyword `prototype` on the object before adding the custom property to it as follows: + +```js +// First, create the “bicycle” object +function bicycle() {} +// Assign the wheels property to the object’s prototype +bicycle.prototype.wheels = 2; +``` + +All instances of `bicycle()` will now have the `wheels` property prebuilt into them. + +The same approach is used in V8 with templates. Each `FunctionTemplate` has a `PrototypeTemplate` method which gives a template for the function’s prototype. You can set properties, and associate C++ functions with those properties, on a `PrototypeTemplate` which will then be present on all instances of the corresponding `FunctionTemplate`. For example: + +```cpp +v8::Local biketemplate = v8::FunctionTemplate::New(isolate); +biketemplate->PrototypeTemplate()->Set( + v8::String::NewFromUtf8Literal(isolate, "wheels"), + v8::FunctionTemplate::New(isolate, MyWheelsMethodCallback) +); +``` + +This causes all instances of `biketemplate` to have a `wheels` method in their prototype chain which, when called, causes the C++ function `MyWheelsMethodCallback` to be called. + +V8’s `FunctionTemplate` class provides the public member function `Inherit()` which you can call when you want a function template to inherit from another function template, as follows: + +```cpp +void Inherit(v8::Local parent); +``` diff --git a/deps/v8/docs/evaluate-code-coverage.md b/deps/v8/docs/evaluate-code-coverage.md new file mode 100644 index 00000000000000..1ab41432bc9b0f --- /dev/null +++ b/deps/v8/docs/evaluate-code-coverage.md @@ -0,0 +1,35 @@ +--- +title: 'Evaluating code coverage' +description: 'This document explains what to do if you’re working on a change in V8 and you want to evaluate its code coverage.' +--- +You are working on a change. You want to evaluate code coverage for your new code. + +V8 provides two tools for doing this: local, on your machine; and build infrastructure support. + +## Local + +Relative to the root of the v8 repo, use `./tools/gcov.sh` (tested on linux). This uses gnu’s code coverage tooling and some scripting to produce an HTML report, where you can drill down coverage info per directory, file, and then down to line of code. + +The script builds V8 under a separate `out` directory, using `gcov` settings. We use a separate directory to avoid clobbering your normal build settings. This separate directory is called `cov` — it is created immediately under the repo root. `gcov.sh` then runs the test suite, and produces the report. The path to the report is provided when the script completes. + +If your change has architecture specific components, you can cumulatively collect coverage from architecture specific runs. + +```bash +./tools/gcov.sh x64 arm +``` + +This rebuilds in-place for each architecture, clobbering the binaries from the previous run, but preserving and accumulating over the coverage results. + +By default, the script collects from `Release` runs. If you want `Debug`, you may specify so: + +```bash +BUILD_TYPE=Debug ./tools/gcov.sh x64 arm arm64 +``` + +Running the script with no options will provide a summary of options as well. + +## Code coverage bot + +For each change that landed, we run a x64 coverage analysis — see the [coverage bot](https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20gcov%20coverage). We don't run bots for coverage for other architectures. + +To get the report for a particular run, you want to list the build steps, find the “gsutil coverage report” one (towards the end), and open the “report” under it. diff --git a/deps/v8/docs/feature-launch-process.md b/deps/v8/docs/feature-launch-process.md new file mode 100644 index 00000000000000..9fa8316c1c4496 --- /dev/null +++ b/deps/v8/docs/feature-launch-process.md @@ -0,0 +1,83 @@ +--- +title: 'Implementing and shipping JavaScript/WebAssembly language features' +description: 'This document explains the process for implementing and shipping JavaScript or WebAssembly language features in V8.' +--- +In general, V8 follows the [Blink Intent process for already-defined consensus-based standards](https://www.chromium.org/blink/launching-features/#process-existing-standard) for JavaScript and WebAssembly language features. V8-specific errata are laid out below. Please follow the Blink Intent process, unless the errata tells you otherwise. + +If you have any questions on this topic for JavaScript features, please email syg@chromium.org and v8-dev@googlegroups.com. + +For WebAssembly features, please email gdeepti@chromium.org and v8-dev@googlegroups.com. + +## Errata + +### JavaScript features usually wait until Stage 3+ { #stage3plus } + +As a rule of thumb, V8 waits to implement JavaScript feature proposals until they advance to [Stage 3 or later in TC39](https://tc39.es/process-document/). TC39 has its own consensus process, and Stage 3 or later signals explicit consensus among TC39 delegates, including all browser vendors, that a feature proposal is ready to implement. This external consensus process means Stage 3+ features do not need to send Intent emails other than Intent to Ship. + +### TAG review { #tag } + +For smaller JavaScript or WebAssembly features, a TAG review is not required, as TC39 and the Wasm CG already provide significant technical oversight. If the feature is large or cross-cutting (e.g., requires changes to other Web Platform APIs or modifications to Chromium), TAG review is recommended. + +### Both V8 and blink flags are required { #flags } + +When implementing a feature, both a V8 flag and a blink `base::Feature` are required. + +Blink features are required so that Chrome can turn off features without distributing new binaries in emergency situations. This is usually implemented in [`gin/gin_features.h`](https://source.chromium.org/chromium/chromium/src/+/main:gin/gin_features.h), [`gin/gin_features.cc`](https://source.chromium.org/chromium/chromium/src/+/main:gin/gin_features.cc), and [`gin/v8_initializer.cc`](https://source.chromium.org/chromium/chromium/src/+/main:gin/v8_initializer.cc), + +### Fuzzing is required to ship { #fuzzing } + +JavaScript and WebAssembly features must be fuzzed for a minimum period of 4 weeks, or one (1) release milestone, with all fuzz bugs fixed, before they can be shipped. + +For code-complete JavaScript features, start fuzzing by moving the feature flag to the `JAVASCRIPT_STAGED_FEATURES_BASE` macro in [`src/flags/flag-definitions.h`](https://crsrc.org/c/v8/src/flags/flag-definitions.h). + +For WebAssembly, see the [WebAssembly shipping checklist](/docs/wasm-shipping-checklist). + +### [Chromestatus](https://chromestatus.com/) and review gates { #chromestatus } + +The blink intent process includes a series of review gates that must be approved on the feature's entry in [Chromestatus](https://chromestatus.com/) before an Intent to Ship is sent out seeking API OWNER approvals. + +These gates are tailored towards web APIs, and some gates may not be applicable to JavaScript and WebAssembly features. The following is broad guidance. The specifics differ from feature to feature; do not apply guidance blindly! + +#### Privacy + +Most JavaScript and WebAssembly features do not affect privacy. Rarely, features may add new fingerprinting vectors that reveal information about a user's operating system or hardware. + +#### Security + +While JavaScript and WebAssembly are common attack vectors in security exploits, most new features do not add additional attack surface. [Fuzzing](#fuzzing) is required, and mitigates some of the risk. + +Features that affect known popular attack vectors, such as `ArrayBuffer`s in JavaScript, and features that might enable side-channel attacks, need extra scrutiny and must be reviewed. + +#### Enterprise + +Throughout their standardization process in TC39 and the Wasm CG, JavaScript and WebAssembly features already undergo heavy backwards compatibility scrutiny. It is exceedingly rare for features to be willfuly backwards incompatible. + +For JavaScript, recently shipped features can also be disabled via `chrome://flags/#disable-javascript-harmony-shipping`. + +#### Debuggability + +JavaScript and WebAssembly features' debuggability differs significantly from feature to feature. JavaScript features that only add new built-in methods do not need additional debugger support, while WebAssembly features that add new capabilities may need significant additional debugger support. + +For more details, see the [JavaScript feature debugging checklist](https://docs.google.com/document/d/1_DBgJ9eowJJwZYtY6HdiyrizzWzwXVkG5Kt8s3TccYE/edit#heading=h.u5lyedo73aa9) and the [WebAssembly feature debugging checklist](https://goo.gle/devtools-wasm-checklist). + +When in doubt, this gate is applicable. + +#### Testing { #tests } + +Instead of WPT, Test262 tests are sufficient for JavaScript features, and WebAssembly spec tests are sufficient for WebAssembly features. + +Adding Web Platform Tests (WPT) is not required, as JavaScript and WebAssembly language features have their own interoperable test repositories that are run by multiple implementations. Feel free to add some though, if you think it is beneficial. + +For JavaScript features, explicit correctness tests in [Test262](https://github.com/tc39/test262) are required. Note that tests in the [staging directory](https://github.com/tc39/test262/blob/main/CONTRIBUTING.md#staging) suffice. + +For WebAssembly features, explicit correctness tests in the [WebAssembly Spec Test repo](https://github.com/WebAssembly/spec/tree/main/test) are required. + +For performance tests, JavaScript already underlies most existing performance benchmarks, like Speedometer. + +### Who to CC { #cc } + +**Every** “intent to `$something`” email (e.g. “intent to implement”) should CC in addition to . This way, other embedders of V8 are kept in the loop too. + +### Link to the spec repo { #spec } + +The Blink Intent process requires an explainer. Instead of writing a new doc, feel free to link to respective spec repository instead (e.g. [`import.meta`](https://github.com/tc39/proposal-import-meta)). diff --git a/deps/v8/docs/flake-bisect.md b/deps/v8/docs/flake-bisect.md new file mode 100644 index 00000000000000..f7b99d0f8a4820 --- /dev/null +++ b/deps/v8/docs/flake-bisect.md @@ -0,0 +1,72 @@ +--- +title: 'Flake bisect' +description: 'This document explains how to bisect flaky tests.' +--- +Flaky tests are reported in a separate step on the bots ([example build](https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/38630/overview)). + +Each test log provides a pre-filled command line for triggering an automated flake bisect, like: + +``` +Trigger flake bisect on command line: +bb add v8/try.triggered/v8_flako -p 'to_revision="deadbeef"' -p 'test_name="MyTest"' ... +``` + +Before triggering flake bisects for the first time, users must log in with a google.com account: + +```bash +bb auth-login +``` + +Then execute the provided command, which returns a build URL running flake bisect ([example](https://ci.chromium.org/ui/p/v8/builders/try.triggered/v8_flako/b8836020260675019825/overview)). + +If you’re in luck, bisection points you to a suspect. If not, you might want to read further… + +## Detailed description + +For technical details, see also the implementation [tracker bug](https://crbug.com/711249). The flake bisect approach has the same intentions as [findit](https://sites.google.com/chromium.org/cat/findit), but uses a different implementation. + +### How does it work? + +A bisect job has 3 phases: calibration, backwards and inwards bisection. During calibration, testing is repeated doubling the total timeout (or the number of repetitions) until enough flakes are detected in one run. Then, backwards bisection doubles the git range until a revision without flakes is found. At last, we bisect into the range of the good revision and the oldest bad one. Note, bisection doesn't produce new build products, it is purely based on builds previously created on V8's continuous infrastructure. + +### Bisection fails when… + +- No confidence can be reached during calibration. This is typical for one-in-a-million flakes or flaky behavior only visible when other tests run in parallel (e.g. memory hungry tests). +- The culprit is too old. Bisection bails out after a certain number of steps, or if older builds are not available anymore on the isolate server. +- The overall bisect job times out. In this case it might be possible to restart it with an older known bad revision. + +## Properties for customizing flake bisect + +- `extra_args`: Extra arguments passed to V8’s `run-tests.py` script. +- repetitions: Initial number of test repetitions (passed to `run-tests.py`'s `--random-seed-stress-count` option; unused if `total_timeout_sec` is used). +- `timeout_sec`: Timeout parameter passed to `run-tests.py`. +- `to_revision`: Revision known to be bad. This is where bisection will start. +- `total_timeout_sec`: Initial total timeout for one entire bisect step. During calibration, this time is doubled several times if needed. Set to 0 to disable and use the `repetitions` property instead. +- `variant`: Name of the testing variant passed to `run-tests.py`. + +## Properties you won’t need to change + +- `bisect_buildername`: Master name of the builder that produced the builds for bisection. +- `bisect_mastername`: Name of the builder that produced the builds for bisection. +- `build_config`: Build config passed to V8’s `run-tests.py` script (there the parameter name is `--mode`, example: `Release` or `Debug`). +- `isolated_name`: Name of the isolated file (e.g. `bot_default`, `mjsunit`). +- `swarming_dimensions`: Swarming dimensions classifying the type of bot the tests should run on. Passed as list of strings, each in the format `name:value`. +- `test_name`: Fully qualified test name passed to run-tests.py. E.g. `mjsunit/foobar`. + +## Tips and tricks + +### Bisecting a hanging test (e.g. dead lock) + +If a failing run times out, while a pass is running very fast, it is useful to tweak the timeout_sec parameter, so that bisection is not delayed waiting for the hanging runs to time out. E.g. if the pass is usually reached in <1 second, set the timeout to something small, e.g. 5 seconds. + +### Getting more confidence on a suspect + +In some runs, confidence is very low. E.g. calibration is satisfied if four flakes are seen in one run. During bisection, every run with one or more flakes is counted as bad. In such cases it might be useful to restart the bisect job setting to_revision to the culprit and using a higher number of repetitions or total timeout than the original job and confirm that the same conclusion is reached again. + +### Working around timeout issues + +In case the overall timeout option causes builds to hang, it’s best to estimate a fitting number of repetitions and set `total_timeout_sec` to `0`. + +### Test behavior depending on random seed + +Rarely, a code path is only triggered with a particular random seed. In this case it might be beneficial to fix it using `extra_args`, e.g. `"extra_args": ["--random-seed=123"]`. Otherwise, the stress runner uses different random seeds throughout. Note though that a particular random seed might reproduce a problem in one revision, but not in another. diff --git a/deps/v8/docs/gdb-jit.md b/deps/v8/docs/gdb-jit.md new file mode 100644 index 00000000000000..01efd4573707fe --- /dev/null +++ b/deps/v8/docs/gdb-jit.md @@ -0,0 +1,65 @@ +--- +title: 'GDB JIT Compilation Interface integration' +description: 'GDB JIT Compilation Interface integration allows V8 to provide GDB with the symbol and debugging information for native code emitted from the V8 runtime.' +--- +GDB JIT Compilation Interface integration allows V8 to provide GDB with the symbol and debugging information for native code emitted from the V8 runtime. + +When GDB JIT Compilation Interface is disabled a typical backtrace in GDB contains frames marked with `??`. These frames correspond to dynamically generated code: + +``` +#8 0x08281674 in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758 +#9 0xf5cae28e in ?? () +#10 0xf5cc3a0a in ?? () +#11 0xf5cc38f4 in ?? () +#12 0xf5cbef19 in ?? () +#13 0xf5cb09a2 in ?? () +#14 0x0809e0a5 in v8::internal::Invoke (construct=false, func=..., receiver=..., argc=0, args=0x0, + has_pending_exception=0xffffd46f) at src/execution.cc:97 +``` + +However enabling GDB JIT Compilation Interface allows GDB to produce more informative stack trace: + +``` +#6 0x082857fc in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758 +#7 0xf5cae28e in ?? () +#8 0xf5cc3a0a in loop () at test.js:6 +#9 0xf5cc38f4 in test.js () at test.js:13 +#10 0xf5cbef19 in ?? () +#11 0xf5cb09a2 in ?? () +#12 0x0809e1f9 in v8::internal::Invoke (construct=false, func=..., receiver=..., argc=0, args=0x0, + has_pending_exception=0xffffd44f) at src/execution.cc:97 +``` + +Frames still unknown to GDB correspond to native code without source information. See [known limitations](#known-limitations) for more details. + +GDB JIT Compilation Interface is specified in the GDB documentation: + +## Prerequisites + +- V8 v3.0.9 or newer +- GDB 7.0 or newer +- Linux OS +- CPU with Intel-compatible architecture (ia32 or x64) + +## Enabling GDB JIT Compilation Interface + +GDB JIT Compilation Interface is currently excluded from the compilation by default and disabled in runtime. To enable it: + +1. Build V8 library with `ENABLE_GDB_JIT_INTERFACE` defined. If you are using scons to build V8 run it with `gdbjit=on`. +1. Pass `--gdbjit` flag when starting V8. + +To check that you have enabled GDB JIT integration correctly try setting a breakpoint on `__jit_debug_register_code`. This function is invoked to notify GDB about new code objects. + +## Known limitations + +- GDB side of JIT Interface currently (as of GDB 7.2) does not handle registration of code objects very effectively. Each next registration takes more time: with 500 registered objects each next registration takes more than 50ms, with 1000 registered code objects - more than 300 ms. This problem was [reported to GDB developers](https://sourceware.org/ml/gdb/2011-01/msg00002.html) but currently there is no solution available. To reduce pressure on GDB current implementation of GDB JIT integration operates in two modes: _default_ and _full_ (enabled by `--gdbjit-full` flag). In _default_ mode V8 notifies GDB only about code objects that have source information attached (this usually includes all user scripts). In _full_ - about all generated code objects (stubs, ICs, trampolines). + +- On x64 GDB is unable to properly unwind stack without `.eh_frame` section ([Issue 1053](https://bugs.chromium.org/p/v8/issues/detail?id=1053)) + +- GDB is not notified about code deserialized from the snapshot ([Issue 1054](https://bugs.chromium.org/p/v8/issues/detail?id=1054)) + +- Only Linux OS on Intel-compatible CPUs is supported. For different OSes either a different ELF-header should be generated or a completely different object format should be used. + +- Enabling GDB JIT interface disables compacting GC. This is done to reduce pressure on GDB as unregistering and registering each moved code object will incur considerable overhead. + +- GDB JIT integration provides only _approximate_ source information. It does not provide any information about local variables, function’s arguments, stack layout etc. It does not enable stepping through JavaScript code or setting breakpoint on the given line. However one can set a breakpoint on a function by its name. diff --git a/deps/v8/docs/gdb.md b/deps/v8/docs/gdb.md new file mode 100644 index 00000000000000..c63bf7f7c6a254 --- /dev/null +++ b/deps/v8/docs/gdb.md @@ -0,0 +1,40 @@ +--- +title: 'Debugging builtins with GDB' +description: 'As of V8 v6.9, it’s possible to create breakpoints in GDB to debug CSA / ASM / Torque builtins.' +--- +As of V8 v6.9, it’s possible to create breakpoints in GDB (and possibly other debuggers) to debug CSA / ASM / Torque builtins. + +``` +(gdb) tb i::Isolate::Init +Temporary breakpoint 1 at 0x7ffff706742b: i::Isolate::Init. (2 locations) +(gdb) r +Thread 1 "d8" hit Temporary breakpoint 1, 0x00007ffff7c55bc0 in Isolate::Init +(gdb) br Builtins_RegExpPrototypeExec +Breakpoint 2 at 0x7ffff7ac8784 +(gdb) c +Thread 1 "d8" hit Breakpoint 2, 0x00007ffff7ac8784 in Builtins_RegExpPrototypeExec () +``` + +Note that it works well to use a temporary breakpoint (shortcut `tb` in GDB) instead of a regular breakpoint (`br`) for this, since you only need it at process start. + +Builtins are also visible in stack traces: + +``` +(gdb) bt +#0 0x00007ffff7ac8784 in Builtins_RegExpPrototypeExec () +#1 0x00007ffff78f5066 in Builtins_ArgumentsAdaptorTrampoline () +#2 0x000039751d2825b1 in ?? () +#3 0x000037ef23a0fa59 in ?? () +#4 0x0000000000000000 in ?? () +``` + +Caveats: + +- Only works with embedded builtins. +- Breakpoints can only be set at the start of the builtin. +- The initial breakpoint in `Isolate::Init` is needed prior to setting the builtin breakpoint, since GDB modifies the binary and we verify a hash of the builtins section in the binary at startup. Otherwise, V8 complains about a hash mismatch: + + ``` + # Fatal error in ../../src/isolate.cc, line 117 + # Check failed: d.Hash() == d.CreateHash() (11095509419988753467 vs. 3539781814546519144). + ``` diff --git a/deps/v8/docs/heap/compaction.md b/deps/v8/docs/heap/compaction.md new file mode 100644 index 00000000000000..613f21fe36a92d --- /dev/null +++ b/deps/v8/docs/heap/compaction.md @@ -0,0 +1,43 @@ +# Heap Compaction in V8 + +Compaction is a phase of the Major Garbage Collector (Mark-Sweep-Compact) used to resolve memory fragmentation in the Old Generation and other spaces. + +## Overview + +Over time, as objects are allocated and freed, the heap can become fragmented—full of small free spaces that are too small to satisfy new allocation requests. Compaction solves this by moving live objects closer together, creating large contiguous free spaces. + +## The Compaction Pipeline + +### 1. Identification of Evacuation Candidates +V8 does not compact the entire heap at once, as that would cause unacceptably long pause times. Instead, it identifies specific pages as "evacuation candidates" in `CollectEvacuationCandidates`: +* **Thresholds**: V8 calculates a fragmentation threshold. Pages with free space exceeding this threshold are considered candidates. +* **Heuristics**: To bound pause times, V8 limits the total size of objects to be evacuated (`max_evacuated_bytes`). It sorts candidate pages by the amount of **live bytes in ascending order** (i.e., pages with the most free space first). It then selects the candidates that fit within the limit, maximizing reclaimed space per byte moved. +* **Heuristics calculation**: `ComputeEvacuationHeuristics` determines the target fragmentation and max evacuated bytes based on the mode (ReduceMemory, OptimizeForMemoryUsage, or regular latency-critical mode). In regular mode, it may use trace-based compaction speed to adaptively set the threshold. +* **Spaces**: Compaction is performed on `OLD_SPACE`, `TRUSTED_SPACE`, and potentially `CODE_SPACE` and `SHARED_SPACE` (with specific conditions, e.g., not compacting shared space when CSS is enabled in certain modes). + +### 2. Parallel Evacuation +The actual moving of objects happens in parallel to utilize multiple cores: +* **Page Promotion**: For some pages in the new space (or if forced due to stack scanning limitations), V8 might promote the **entire page** to the old generation simply by updating metadata, without copying objects. +* **Object Evacuation**: For pages that must be compacted, V8 iterates over live objects and copies them to newly allocated spaces in non-candidate pages. + +### 3. Forwarding Addresses +When an object is moved to a new location: +* V8 overwrites the original object's map word with a **forwarding address** pointing to the new location. +* This forwarding address is crucial for updating pointers that still point to the old location. + +### 4. Pointer Updating +After all objects have been moved, V8 must update all references to point to the new locations in `UpdatePointersAfterEvacuation`: +* **Roots**: V8 scans all roots (stack, handles, etc.) and updates pointers to moved objects. +* **Remembered Sets**: V8 processes remembered sets to update inter-object references across the heap. This includes: + * `OLD_TO_NEW`: Pointers from old to new generation. + * `OLD_TO_SHARED`: Pointers from non-shared to shared space. + * `OLD_TO_OLD`: Pointers between old generation pages, specifically recorded when the target points to an evacuation candidate. + * `TRUSTED_TO_CODE`: Pointers from trusted space to code space. + * `TRUSTED_TO_TRUSTED`: Pointers within trusted space. + * `TRUSTED_TO_SHARED_TRUSTED`: Pointers from trusted space to shared trusted space. + +## Additional Compaction Areas +* **External Pointer Tables**: With the V8 Sandbox enabled, external pointer tables (young, old, cpp_heap) are also compacted if needed, starting at the beginning of the marking phase in `StartMarking`. + +## File Structure +* `src/heap/mark-compact.cc`: Contains the implementation of the compaction logic, including candidate selection, evacuation, and pointer updating. diff --git a/deps/v8/docs/heap/garbage-collection.md b/deps/v8/docs/heap/garbage-collection.md new file mode 100644 index 00000000000000..f5489eef166e55 --- /dev/null +++ b/deps/v8/docs/heap/garbage-collection.md @@ -0,0 +1,72 @@ +# Garbage Collection in V8 + +V8 uses a sophisticated garbage collection (GC) system to automatically manage memory. It is a generational collector, meaning it divides the heap into different generations based on object lifetime. + +## Generational Hypothesis + +The GC is based on the generational hypothesis: most objects die young. By dividing the heap into young and old generations, V8 can optimize GC pauses by collecting the young generation more frequently and quickly. + +## The Young Generation + +The Young Generation is where newly allocated objects are placed. It is typically small (a few megabytes to tens of megabytes) and is designed to be collected quickly. + +### Scavenger (Minor GC) + +The default collector for the young generation is the **Scavenger**. It uses a semi-space design: +1. The young generation is divided into two halves: **To-Space** and **From-Space**. +2. New objects are allocated in To-Space. +3. When To-Space is full, a Scavenge cycle begins. +4. At the start of the cycle, the roles of To-Space and From-Space are swapped. The space containing the new objects becomes **From-Space**, and the empty space becomes **To-Space**. +5. The Scavenger traces live objects in From-Space and copies them to To-Space (or promotes them to the Old Generation if they have survived a previous cycle). + +This is a copying collector, which compacts memory as it goes, leaving no fragmentation in the young generation. + +### Minor Mark-Sweep (Minor MS) (Not enabled by default) + +**Minor Mark-Sweep** is an alternative young generation collector in V8, enabled with the `--minor-ms` flag. Unlike the Scavenger, which is a copying collector, Minor MS uses a mark-sweep approach. + +* **Goal**: Avoid the overhead of copying objects and reduce memory fragmentation in certain workloads. +* **Mechanism**: + * **Marking**: It marks objects reachable from roots and remembered sets (`OLD_TO_NEW`). It supports concurrent and parallel marking. + * **Non-Moving**: It generally does not move objects (unlike the Scavenger). + * **Page Promotion**: Instead of copying individual objects to the old generation, Minor MS can promote **entire pages** to the old generation if they have a high survival rate. + * **Sweeping**: Pages that are not promoted are swept to reclaim memory from dead objects. Sweeping can also be done concurrently. +* **File**: `src/heap/minor-mark-sweep.cc` + +## The Old Generation + +Objects that survive a certain number of Scavenge cycles in the young generation are promoted (tenured) to the **Old Generation**. This space is much larger and contains long-lived objects. + +### Mark-Sweep-Compact (Major GC) + +The Old Generation is collected by the **Mark-Sweep-Compact** collector. This is a much more involved process: + +1. **Marking**: The collector traverses the object graph starting from roots (stack, global objects, etc.) and marks all reachable objects as live. V8 uses **Incremental Marking** and **Concurrent Marking** to do most of this work while the main JavaScript thread is running, minimizing pause times. +2. **Sweeping**: The collector scans the heap and adds memory occupied by dead objects (unmarked) to free lists, making it available for future allocations. This can also be done concurrently. +3. **Compaction**: Over time, the old generation can become fragmented. The collector may choose to compact certain pages by moving live objects together and updating pointers, to create large contiguous free spaces. + +## Write Barriers + +To support generational GC and incremental marking without scanning the entire heap, V8 uses **Write Barriers**. A write barrier is code emitted for heap stores like `host.field = value` to inform the GC about changes to the object graph. + +The write barrier serves three main purposes (as detailed in `src/heap/WRITE_BARRIER.md`): +1. **Generational Barrier (Old-to-New)**: Records references from the Old Generation to the Young Generation in a **Remembered Set** (`OLD_TO_NEW`). This allows the Scavenger to find live young objects without scanning the whole old generation. This barrier is always enabled. +2. **Marking Barrier**: Prevents "black-to-white" references during incremental or concurrent marking. If a black (already traced) object is updated to point to a white (untraced) object, the marking barrier ensures the target object is marked or pushed to the worklist. +3. **Evacuation Barrier (Old-to-Old)**: Records references between old objects when the target resides on an evacuation candidate page, to update pointers after compaction. + +### Eliminating Write Barriers +Write barriers add overhead, so V8 eliminates them when safe: +* **Smi or Read-Only**: Storing a Smi or a pointer to a read-only object never needs a barrier. +* **Initializing Stores**: Storing into the most recently allocated young object (before any potential GC point) does not need a barrier. + +## Concurrent and Parallel GC + +To achieve low latency, V8 heavily utilizes background threads: +- **Parallel**: The main thread and worker threads do GC work at the same time (e.g., Parallel Scavenge). +- **Concurrent**: Worker threads do GC work while the main thread is running JavaScript (e.g., Concurrent Marking and Sweeping). + +## See Also +- [Pointer Tagging](pointer-tagging.md) +- [Objects and Maps](objects-and-maps.md) +- [Marking and Sweeping](marking-and-sweeping.md) +- [Heap Compaction](compaction.md) diff --git a/deps/v8/docs/heap/handles.md b/deps/v8/docs/heap/handles.md new file mode 100644 index 00000000000000..0f563b93c015b9 --- /dev/null +++ b/deps/v8/docs/heap/handles.md @@ -0,0 +1,60 @@ +# Handles in V8 + +Handles are the primary mechanism in V8 for referencing heap objects in C++ code in a way that is safe for garbage collection. Because V8's garbage collector moves objects during compaction, raw C++ pointers to heap objects would become invalid. Handles solve this by adding a layer of indirection or by collaborating with conservative stack scanning. + +This document focuses on **internal** handles used within the V8 implementation. For external handles used by embedders, see the public API (e.g., `v8::Local` and `v8::Persistent`). + +## Types of Handles + +V8 provides two main types of internal handles: **Indirect Handles** (`Handle` or explicitly `IndirectHandle`) and **Direct Handles** (`DirectHandle`). + +### 1. Indirect Handles (`Handle`) + +Indirect handles are the traditional handle type in V8. +* **Representation**: A `Handle` is a pointer to a location (usually in a `HandleScope`) that contains the actual tagged pointer to the `HeapObject`. +* **GC Safety**: When the GC moves an object, it updates the pointer in the `HandleScope` slot. All `Handle` instances pointing to that slot automatically see the new location. +* **Usage**: Used widely across the codebase. + +### 2. Direct Handles (`DirectHandle`) + +Direct handles are an optimization intended to reduce the overhead of indirection. +* **Representation**: + * When `V8_ENABLE_DIRECT_HANDLE` is enabled: A `DirectHandle` is a direct wrapper around a tagged pointer to a heap object or Smi. It does NOT use a slot in a `HandleScope`. + * When `V8_ENABLE_DIRECT_HANDLE` is NOT enabled: It is a wrapper around an `IndirectHandle`, serving as a fallback. (Note: `DirectHandle` is often used interchangeably with `Handle` in API signatures that accept both). +* **GC Safety**: When enabled, direct handles rely on **Conservative Stack Scanning (CSS)**. The GC scans the C++ stack to find potential pointers to heap objects. If a direct handle is on the stack, the GC will find it and update it if the object moves. DirectHandles are *only* valid thanks to CSS finding them on the stack. +* **Usage**: They should only be used on the stack (enforced by C++ type traits in debug builds). They must not be stored in heap objects or global structures. + +## Handle Scopes (`HandleScope`) + +Local handles are managed in the context of a `HandleScope`. +* **Indirect Handles**: A `HandleScope` accumulates slots for handles created within its scope. When the `HandleScope` is destroyed (typically at the end of a C++ function scope), all handles created within it become invalid because their slots are reclaimed. This prevents memory leaks from handles accumulating indefinitely. +* **Direct Handles**: While direct handles do not use `HandleScope` slots, they are still conceptually local. They must only live on the stack and are valid as long as the object they point to is kept alive by some other means (e.g., an indirect handle in a scope) or if they are tracked by CSS. +* **GC Interaction**: `HandleScope` instances are considered roots by the GC. The GC walks all active `HandleScope` slots during the main thread pause to update pointers to moved objects. + +## Global and Eternal Handles + +For objects that need to live beyond the scope of a function or a single turn, V8 provides global handles. + +### Global Handles (`GlobalHandles`) +* Independent of stack state. +* Can be strong or weak (with callbacks/finalizers). +* Used for embedding V8 in applications (e.g., keeping a reference to a JS object from C++). + +### Eternal Handles (`EternalHandles`) +* Handles that never go away. +* Cheaper than global handles because they don't need to be tracked for destruction. + +## Maybe Handles + +V8 also provides `MaybeHandle` and `MaybeDirectHandle`. +* These represent a handle that may be empty (null). +* They force validation (checking for emptiness) before they can be converted to regular handles and used. +* This is similar to `std::optional` or a nullable pointer, but specifically for handles. + +## Migration to Direct Handles + +V8 is in the process of migrating to `DirectHandle` where appropriate to improve performance. +* Direct handles avoid the memory overhead of allocating slots in `HandleScope`. +* They avoid the indirection cost when accessing the object. +* **Default Status**: Handles are now by default direct handles if pointer compression is enabled (which it is by default on 64-bit platforms), and V8 is moving towards making them the only kind of handle, except where indirect handles are explicitly required. +* **Rule**: Use `DirectHandle` for local variables on the stack. Code should be written to use `DirectHandle` where possible, as it will fallback to `Handle` if direct handles are not enabled. diff --git a/deps/v8/docs/heap/heap-overview.md b/deps/v8/docs/heap/heap-overview.md new file mode 100644 index 00000000000000..ae8c7388e0ebe9 --- /dev/null +++ b/deps/v8/docs/heap/heap-overview.md @@ -0,0 +1,57 @@ +# Heap Overview in V8 + +V8 manages its own heap memory, organized into several "spaces" to optimize allocation and garbage collection. + +## Paged Space + +Most spaces in the V8 heap are divided into **Pages** (typically 256KB or 512KB depending on architecture). +* **Allocation**: Objects are allocated linearly within a page (bump-pointer allocation) until the page is full, after which a new page is acquired. +* **Management**: Pages are managed by the `MemoryAllocator` and belong to specific spaces. + +## Heap Objects and Maps + +Every object allocated on the V8 heap (a `HeapObject`) has a common header structure. The very first word of every `HeapObject` is a tagged pointer to a **Map** (also known as a hidden class or shape). + +### The Role of the Map + +The Map is crucial because it contains metadata that allows V8 to understand the object's structure without inspecting the object itself: +1. **Type**: The `InstanceType` (e.g., `JS_OBJECT_TYPE`, `STRING_TYPE`, `FIXED_ARRAY_TYPE`) identifies what kind of object it is. +2. **Size**: The `instance_size` tells V8 how many bytes the object occupies. +3. **Iteration**: The `visitor_id` tells the garbage collector how to iterate over the pointers contained within the object body (e.g., which fields are tagged pointers vs raw data). + * **BodyDescriptors**: V8 uses `BodyDescriptor` classes (e.g., `JSObject::BodyDescriptor`) to provide a static way to iterate over object bodies. The `visitor_id` maps to these descriptors to guide the GC without needing virtual calls for every object. + +### Example and Diagram + +Consider a simple JavaScript object: +```javascript +const obj = { a: 1, b: 2 }; +``` + +In the heap, this `JSObject` might look like this: + +```dot +digraph G { + rankdir=LR; + newrank=true; + node [shape=record, style=filled]; + + jsobject [label=" JSObject | Map Pointer | Properties Pointer | Elements Pointer | In-Object 'a': 1 | In-Object 'b': 2"]; + map [label=" Map | InstanceType: JS_OBJECT_TYPE | InstanceSize: 32 bytes | VisitorID: JSObjectVisitor | DescriptorArray"]; + empty_array [label="EmptyFixedArray", shape=ellipse]; + + jsobject:map -> map:head; + jsobject:props -> empty_array; + jsobject:elems -> empty_array; +} +``` + +Every heap access starts by reading the Map to know how to handle the rest of the object! + +## Spaces in the Heap +V8 divides the heap into several spaces: +* **New Space**: For young objects (nursery). Uses Cheney's copy algorithm. +* **Old Space**: For objects that survived New Space. +* **Read-Only Space**: For shared, immutable objects. +* **Large Object Space**: For objects larger than a page. +* **Code Space**: For executable instructions. +* **Trusted Space**: For objects that must be protected from corruption (when Sandbox is enabled). diff --git a/deps/v8/docs/heap/marking-and-sweeping.md b/deps/v8/docs/heap/marking-and-sweeping.md new file mode 100644 index 00000000000000..6f35ebf38bbccb --- /dev/null +++ b/deps/v8/docs/heap/marking-and-sweeping.md @@ -0,0 +1,92 @@ +# Marking and Sweeping in V8 + +This document provides a deep dive into the implementation of the Mark-Sweep-Compact garbage collection algorithm used in V8's Old Generation (Major GC). + +## Overview + +The Major GC in V8 follows three main phases: +1. **Marking**: Identifying live objects. +2. **Sweeping**: Reclaiming memory from dead objects. +3. **Compaction**: Defragmenting the heap by moving live objects (optional, performed when needed). + +## 1. Marking + +V8 uses a bitmap-based marking approach combined with a worklist to achieve efficient and concurrent marking. + +* **Black (Processed)**: The object is live, and all its fields have been scanned. Its bit in the bitmap is `1`, and it is **not** in the worklist. + +### Main Thread Marking and Weakness +While background threads do most of the marking, the main thread is responsible for: +1. **Marking Roots**: This includes the stack, global handles, and other roots that are not safe to access concurrently. +2. **Processing Weak References**: Objects pushed to the weak worklists (e.g., `WeakCell`) are processed at the end of marking on the main thread when the transitive closure is known. + +### The Marking Bitmap +Defined in `src/heap/marking.h`, the `MarkingBitmap` is a sequence of cells containing bits. Each page in the heap has an associated marking bitmap. +* Bits are mapped to tagged object addresses. +* Atomic operations are used when setting bits concurrently. + +### MarkingVisitor +The `MarkingVisitor` (defined in `src/heap/marking-visitor.h`) is responsible for traversing the object graph. +* It pops grey objects from the worklist. +* It iterates through the object's pointers (using `BodyDescriptor`). +* For each pointed-to object, if it is not yet marked, the visitor marks it in the bitmap and pushes it to the worklist (making it grey). + +### Concurrent Marking +To reduce pause times, V8 performs marking concurrently on background threads while the main thread continues to execute JavaScript. + +#### Worklist and Work Stealing +* **Segments**: The `MarkingWorklist` uses thread-local segments for pushing and popping objects to avoid synchronization overhead. +* **Global Pool**: When a segment becomes full, it is published to a shared global pool. Other threads that run out of work can "steal" segments from this pool. + +#### The Write Barrier +To support both generational GC and concurrent marking, V8 uses a **Combined Write Barrier**. Whenever a pointer is written to a heap object (`object.field = value`), the barrier checks: +1. **Generational/Shared Barrier**: If the `object` is in the old generation and the `value` is in the young generation (or shared heap), the slot is recorded in a remembered set. +2. **Marking Barrier**: If incremental marking is active, and the `value` is a white object (unmarked), it is atomically marked grey and pushed to the marking worklist. + +* *Optimization*: The fast path of the write barrier checks if the host object's page requires tracking pointers from it, and if the value object's page requires tracking pointers to it, avoiding deeper checks in most cases. + +#### On-Hold Worklist +Concurrent marking introduces data races if a background thread reads an object while the main thread modifies it. +* To avoid races with the mutator allocating in the Linear Allocation Area (LAB) of the new space, background threads **bail out** of visiting objects that are located in the current LAB. +* These objects are pushed to an **On-Hold Worklist**. + +### Forwarding Pointers and Compaction +During the compaction phase, live objects are moved to new locations. +* To update pointers to moved objects, V8 leaves a **forwarding pointer** in the original object's map word. +* The forwarding pointer encodes the new address of the object. +* For more details on compaction, see [Compaction in V8](compaction.md). +* The on-hold worklist is processed by the main thread or merged back to the shared worklist when it is safe (e.g., at a safepoint where LABs are flushed). +* *Note*: The term "Bailout Worklist" is used in `cppgc` (V8's C++ garbage collector) for objects that cannot be traced concurrently, but in the V8 JS heap, it is referred to as the on-hold worklist. + +#### Handling Object Layout Changes and Transitions +If the main thread changes an object's layout (e.g., transitioning a field from tagged to untagged) or transitions a string while a background thread is scanning it, it could cause a crash or inconsistent state. +* For certain objects like strings that may transition concurrently, V8 uses **Object Locks** (see `ObjectLockGuard`) to ensure exclusive access during scanning by background threads. +* For other complex transitions, V8 ensures synchronization through careful ordering of operations and memory barriers, rather than a generic bailout mechanism for all layout changes. + +## 2. Sweeping + +After marking completes, all objects with a `0` in the marking bitmap are considered dead. + +The `Sweeper` (defined in `src/heap/sweeper.cc`): +* Iterates through the pages of the Old Generation. +* For each page, it identifies contiguous ranges of dead objects. +* It fills these ranges with `Filler` objects (dead space) and adds them to the space's **Free List**. +* Free lists are used by the allocator to find space for new objects. + +Like marking, sweeping is heavily parallelized and can run concurrently with JavaScript execution. + +## 3. Compaction (Evacuation) + +Over time, the Old Generation can become fragmented. Sweeping leaves free spaces, but they might be too small for large objects. + +To combat this, V8 may choose to compact certain pages during a Major GC: +1. **Evacuation**: Live objects on a page selected for compaction are copied to a new page. +2. **Pointer Updating**: All pointers pointing to the moved objects must be updated to point to the new location. This requires recording the locations of all pointers to the evacuated page (remembered sets are also used here). + +Compaction is expensive because it involves copying objects and updating pointers, so V8 only performs it on heavily fragmented pages. + +--- + +## See Also +- [Garbage Collection](garbage-collection.md) +- [Pointer Tagging](pointer-tagging.md) diff --git a/deps/v8/docs/heap/objects-and-maps.md b/deps/v8/docs/heap/objects-and-maps.md new file mode 100644 index 00000000000000..408f2bca98872a --- /dev/null +++ b/deps/v8/docs/heap/objects-and-maps.md @@ -0,0 +1,85 @@ +# Objects and Maps in V8 + +This document describes how JavaScript objects are represented in V8's heap and how "Maps" (also known as hidden classes or shapes) are used to describe their structure. + +## JSObject Layout + +All standard JavaScript objects in V8 are represented by the `JSObject` class (or its subclasses). A `JSObject` typically has the following memory layout: + +1. **Map**: A pointer to the `Map` object that describes the structure of this object. +2. **Properties**: A pointer to a backing store for named properties. This can be: + - `EmptyFixedArray` (if no properties). + - A `Smi` representing the identity hash code. + - A `PropertyArray` for fast properties. + - A `NameDictionary` (or `SwissNameDictionary`) for slow (dictionary mode) properties. + - A `GlobalDictionary` for properties of global objects. +3. **Elements**: A pointer to a backing store for indexed elements (array indices). This can be: + - `FixedArray` for fast elements. + - `NumberDictionary` for slow elements. +4. **In-Object Properties**: Properties that are stored directly within the `JSObject` instance itself, after the header, for faster access. + +## The Map (Hidden Class) + +Every `HeapObject` in V8 has a pointer to a `Map` as its first field. The `Map` is crucial for performance as it enables Inline Caching (IC) for property access. + +A `Map` contains: +- **Instance Size**: The size of the object in bytes. +- **Instance Type**: What kind of object it is (e.g., `JS_OBJECT_TYPE`, `JS_ARRAY_TYPE`, `STRING_TYPE`). +- **Visitor ID**: Used by the garbage collector to know how to iterate over the object's pointers. +- **Property Descriptors**: A pointer to a `DescriptorArray` that describes the names and locations of the object's properties. +- **Transitions**: Information about how the map changes when new properties are added (see below). +- **Prototype**: A pointer to the object's prototype. + +### Simplified Map Layout +(Based on `src/objects/map.h`) + +- `instance_size` (Byte) +- `inobject_properties_start_or_constructor_function_index` (Byte) +- `used_or_unused_instance_size_in_words` (Byte) +- `visitor_id` (Byte) +- `instance_type` (Short) +- `bit_field`, `bit_field2`, `bit_field3` (Bytes/Int) +- `prototype` (TaggedPointer) +- `constructor_or_back_pointer_or_native_context` (TaggedPointer) +- `instance_descriptors` (TaggedPointer) +- `dependent_code` (TaggedPointer) +- `prototype_validity_cell` (TaggedPointer) +- `transitions` or `prototype_info` (TaggedPointer) + +## Named Properties Storage Modes + +V8 uses three different modes to store named properties, balancing access speed and modification flexibility: + +### 1. In-Object Properties +* **Description**: Properties stored directly within the `JSObject` memory layout itself. +* **Performance**: The fastest access available, as it requires no indirection. +* **Limit**: The number of in-object properties is predetermined by the initial size of the object when created. + +### 2. Fast Properties (Out-of-Object) +* **Description**: Properties stored in a linear `PropertyArray` pointed to by the object. +* **Performance**: Adds one level of indirection compared to in-object properties. +* **Mechanism**: To access a property, V8 looks up the property name in the `DescriptorArray` attached to the `Map` to find its index in the `PropertyArray`. +* **Scalability**: The `PropertyArray` can grow independently of the object size. + +### 3. Slow Properties (Dictionary Mode) +* **Description**: Properties stored in a self-contained hash table (`NameDictionary` or `SwissNameDictionary`). +* **Note**: `SwissNameDictionary` is an alternative representation that is currently disabled by default and controlled by the `v8_enable_swiss_name_dictionary` GN argument. +* **Performance**: Slower to access because inline caches do not work with dictionary properties. +* **Use Case**: Used when an object has many properties added and deleted, or when properties are deleted (which disrupts the linear transition tree). +* **Benefits**: Metadata is stored directly in the dictionary rather than being shared via the `Map` and `DescriptorArray`. This avoids creating a massive number of maps for highly dynamic objects. + +--- + +## ElementsAccessor and CRTP + +To avoid duplicating the implementation of array methods (like `slice`, `map`, etc.) for all 20+ different elements kinds, V8 uses a C++ template pattern called **CRTP** (Curiously Recurring Template Pattern) in `ElementsAccessor` (see `src/objects/elements.cc`). +* V8 defines the generic logic once. +* CRTP generates specialized, highly-optimized versions of the array methods for each specific elements kind. + +## Map Transitions + +When a new property is added to an object in fast mode, V8 creates a new map for the object. The old map has a "transition" pointing to the new map for that specific property name. This forms a transition tree, allowing V8 to share maps among objects with the same structure. + +## See Also +- [Pointer Tagging](pointer-tagging.md) +- [Descriptor and Transition Arrays](../objects/descriptor-and-transition-arrays.md) (for more details on descriptors and transitions). diff --git a/deps/v8/docs/heap/pointer-compression.md b/deps/v8/docs/heap/pointer-compression.md new file mode 100644 index 00000000000000..90237e8ce9595a --- /dev/null +++ b/deps/v8/docs/heap/pointer-compression.md @@ -0,0 +1,89 @@ +# Pointer Compression in V8 + +Pointer compression is a technique used in V8 to reduce the memory footprint of the heap on 64-bit architectures. It achieves this by representing 64-bit pointers as 32-bit offsets from a base address, effectively cutting the size of pointer fields in half. + +## How it Works + +When pointer compression is enabled, V8 allocates a large contiguous region of virtual memory called a **Cage** (typically 4GB). + +### Cage Types + +V8 supports two main configurations for the pointer compression cage: +* **Isolate Cage**: Each isolate has its own 4GB cage. The base address is unique per isolate. +* **Shared Cage (Process-wide)**: A single cage is shared across all isolates in a process. This is required for the **V8 Sandbox** (where the cage effectively serves as the sandbox boundary). This mode simplifies sharing of read-only objects and improves performance by avoiding cage base reloads. + +### Compression + +To compress a 64-bit pointer to a 32-bit value: +1. The pointer is verified to be within the designated cage. +2. The pointer is truncated to its lower 32 bits. + +```cpp +// Conceptually +Tagged_t CompressObject(Address tagged) { + return static_cast(tagged); +} +``` + +### Decompression + +To decompress a 32-bit value back to a full 64-bit pointer: +1. The 32-bit value is zero-extended to 64 bits. +2. The zero-extended value is added to the 64-bit **Cage Base** address. + +*Note on Smis*: In their uncompressed representation on 64-bit architectures with pointer compression, Smis explicitly have their top 32 bits undefined (neither guaranteed to be zero nor sign-extended). Operations on Smis *must* truncate to the lower 32 bits and ignore these top bits. This allows decompression to be identical whether the tagged pointer is a Smi or a HeapObject reference (since both just need the lower 32 bits added to the cage base). + +```cpp +// Conceptually +Address DecompressTagged(Tagged_t raw_value) { + Address cage_base = base(); // Get the current cage base + return cage_base + static_cast
(raw_value); +} +``` + +## Cages + +V8 uses different cages for different types of objects to optimize memory layout and security. + +### Main Cage +Used for most JavaScript objects and heap metadata. The base address is typically stored in a dedicated register (`r14` on x64, `x28` on arm64) for fast access during execution. In C++ code, it is accessed via a global variable (if shared cage is enabled) or thread-local storage. + +### Trusted Cage +When the V8 Sandbox is enabled, trusted objects are placed in a separate trusted cage outside the sandbox to prevent them from being corrupted by untrusted code. + +- **Trusted Objects**: These are objects that are trusted to not have been modified in a malicious way. Examples include `BytecodeArray` and `Code`. +- **Exposed Trusted Objects**: Some trusted objects need to be referenced from untrusted objects inside the sandbox. These inherit from `ExposedTrustedObject` and are referenced via **indirect pointers** (indices into a pointer table) to guarantee memory safety. Both `Code` and `BytecodeArray` are exposed trusted objects. +- **Protected Pointers**: Pointers between objects within the trusted cage can be direct compressed pointers, as they cannot be modified by an attacker in the sandbox. + +### External Code Space +When `V8_EXTERNAL_CODE_SPACE` is enabled, the executable instructions of code objects are placed in a separate cage, specifically in `InstructionStream` objects. This allows the code range to be allocated closer to the executable text section of the process, which is sometimes required by operating systems or for performance (shorter jump distances). + +The `Code` object itself (which contains metadata) lives in the Trusted Cage (or Main Cage if sandbox is disabled), while the `InstructionStream` object (which contains the actual machine code) lives in the External Code Space. + +This cage has a slightly more complex decompression scheme to allow it to cross 4GB boundaries. Instead of just adding the 32-bit truncated value to the cage base, it computes the difference between the truncated value and the truncated cage base. If the difference is negative, it adds 4GB to the result. This ensures that the decompressed address is always within the correct 4GB window relative to the cage base. + +```cpp +// Conceptually +Address DecompressExternalCode(Tagged_t raw_value) { + Address cage_base = ExternalCodeCompressionScheme::base(); + uint32_t compressed_value = static_cast(raw_value); + uint32_t compressed_base = static_cast(cage_base); + + intptr_t diff = static_cast(compressed_value) - static_cast(compressed_base); + if (diff < 0) { + diff += 4LL * 1024 * 1024 * 1024; // Add 4GB + } + return cage_base + diff; +} +``` + +## Interaction with Pointer Tagging + +Pointer compression works orthogonally to pointer tagging. The 32-bit compressed value still contains the tag bits in its least significant bits: +- **Smi**: Least significant bit is `0`. +- **HeapObject**: Least significant bit is `1`. + +Decompression preserves these tags because adding the cage base (which is aligned to the cage size, typically at least 4GB, so its lower 32 bits are zero) does not affect the lower bits where the tags reside. + +## See Also +- [Pointer Tagging](pointer-tagging.md) for details on pointer tagging. diff --git a/deps/v8/docs/heap/pointer-tagging.md b/deps/v8/docs/heap/pointer-tagging.md new file mode 100644 index 00000000000000..ef5e9e611570ea --- /dev/null +++ b/deps/v8/docs/heap/pointer-tagging.md @@ -0,0 +1,85 @@ +# Pointer Tagging in V8 + +V8 uses pointer tagging to efficiently represent different types of values in a single word (pointer-sized). This avoids the overhead of separate type tags for every value, which is especially important for small integers (Smis) and heap object references. + +## The Tagging Scheme + +V8 uses the least significant bits of a pointer-sized word to encode the type of the value. + +### Small Integers (Smi) + +Small integers are encoded directly in the pointer word. + +- **Tag**: The least significant bit is `0`. +- **Value**: The remaining bits represent the integer value (shifted). + +#### Smi Representation Details + +The exact representation of Smis depends on the architecture and whether pointer compression is enabled: + +- **32-bit architectures and 64-bit architectures with pointer compression**: + - Smis are 31-bit signed integers. + - They are shifted left by 1 bit. + - The representation is `[31 bits value][0]`. +- **64-bit architectures without pointer compression**: + - Smis are 32-bit signed integers. + - They are shifted left by 32 bits. + - The representation is `[32 bits value][32 bits zeros]`. + - This allows for fast operations on 64-bit systems where the upper 32 bits can be treated as a 32-bit integer directly in some instructions. Specifically, when loading the value from a field, we can increase the load offset by 4 bytes to load just the 32-bit integer payload directly. + - *Note*: This was the default representation on x64 until recently, and is still used if pointer compression is disabled. + +### Heap Objects + +References to objects on the heap are tagged with a non-zero value in the least significant bits. + +- **Strong Reference**: The last two bits are `01`. +- **Weak Reference**: The last two bits are `11`. + * *Note on Weakness*: The distinction between strong and weak references (bit 1 being 0 vs 1) only exists in the slot on the heap. When a weak pointer is loaded into a register to be used as a normal pointer, the weak bit is typically cleared. +- **Constants**: + - `kHeapObjectTag = 1` + - `kWeakHeapObjectTag = 3` + - `kHeapObjectTagMask = 3` + +### Compressed Pointers + +When pointer compression is enabled (the default on 64-bit platforms), pointers are stored as 32-bit values. These compressed pointers are relative to the **isolate's cage base address** (which is often stored in a dedicated register, e.g., `r13` on x64). To decode a compressed pointer to a full 64-bit address, V8 adds it to the cage base. + +Compressed pointers are represented in C++ with the `Tagged_t` type. `Tagged_t` is `uint32_t` when pointer compression is enabled, and `Address` (system-pointer-sized) otherwise. + +#### Forwarding Pointers (GC) + +During garbage collection, V8 uses the least significant bits `00` in the object header (MapWord) to indicate a forwarding pointer to the new location of the object. While this looks like a Smi (LSB is 0), it is only valid in the context of the object header during GC. + +## C++ Representation: `Tagged` + +V8 C++ code uses the `Tagged` template class (defined in `src/objects/tagged.h`) to represent tagged pointers. This provides type safety and encapsulates the tagging operations. + +- `Tagged`: Can represent any tagged value (Smi or HeapObject). +- `Tagged`: Represents a small integer. +- `Tagged`: Represents a pointer to any object on the heap. +- `Tagged`: Represents a pointer to a specific heap object type (e.g., `Tagged`). + +The `Tagged` class handles untagging automatically when dereferencing (e.g., via `operator->`) or when accessing the raw address via `address()`. + +## Address Calculation + +To get the actual memory address of a heap object from a tagged pointer, the tag must be subtracted: + +```cpp +Address address() const { return this->ptr() - kHeapObjectTag; } +``` + +Conversely, to create a tagged pointer from an address, the tag is added: + +```cpp +Tagged(reinterpret_cast
(ptr) + kHeapObjectTag) +``` + +For weak pointers, the weak bit is bitwise-ORed: + +```cpp +return Tagged>(value.ptr() | kWeakHeapObjectTag); +``` + +## See Also +- [Pointer Compression](pointer-compression.md) for how pointer tagging interacts with pointer compression. diff --git a/deps/v8/docs/heap/roots.md b/deps/v8/docs/heap/roots.md new file mode 100644 index 00000000000000..6a11a2f2e9636a --- /dev/null +++ b/deps/v8/docs/heap/roots.md @@ -0,0 +1,46 @@ +# Roots in V8 + +Roots are a set of well-known objects that are always reachable by the garbage collector. They serve as the entry points for heap traversal during GC and provide fast access to frequently used objects and constants. + +## Categories of Roots + +V8 categorizes roots into several lists, defined primarily in `src/roots/roots.h` using X-macros: + +1. **Read-Only Roots**: These are objects that are allocated during isolate initialization and never change. They are placed in the `ReadOnlySpace`. + * **Constants**: `undefined`, `null`, `true`, `false`, `the_hole_value`. + * *Note on Hole Values*: V8 uses multiple specific "hole" values (e.g., `the_hole_value`, `hash_table_hole_value`, `uninitialized_value`) as sentinels in different places. Their bodies are often deliberately unmapped or placed in protected memory so that attempting to read them (for example, as part of a type confusion exploit) will cause a crash, preventing security vulnerabilities. + * **Maps**: Maps for basic types like `ByteArrayMap`, `FixedArrayMap`, `SymbolMap`, etc. + * **Empty Collections**: `EmptyFixedArray`, `EmptyPropertyArray`, etc. +2. **Mutable Immovable Roots**: These objects can be modified but their location in memory is fixed (immortal and immovable). + * **Protectors**: Objects used to invalidate optimizations when certain assumptions change (e.g., `ArraySpeciesProtector`). + * **Caches**: Caches for string splitting, regexps, etc. +3. **Mutable Movable Roots**: These are roots that can be modified and moved by the GC. + * **Public Symbol Table**: The table of registered symbols. + * **Script List**: List of all scripts in the isolate. +4. **Smi Roots**: Small integers stored directly in the roots table for convenience, such as the last script ID. + +## RootsTable and ReadOnlyRoots + +* **`RootsTable`**: This class (defined in `src/roots/roots.h`) encapsulates the array of all roots. It provides accessors to get handles to specific roots. +* **`ReadOnlyRoots`**: A lighter-weight class that provides access *only* to the read-only roots. It can be used even when the full `Isolate` is not available (e.g., on background threads using `LocalIsolate`) because read-only roots are shared or at least stable. + +## Static Roots Optimization + +When `v8_enable_static_roots = true` is enabled (supported under pointer compression, since then read-only pointers are cage-relative), V8 uses a fixed layout for the read-only heap to achieve compile-time constant addresses for core objects. + +### How it Works +* **Cage Placement**: The read-only heap is placed at the very beginning of every Pointer Compression Cage. This ensures that the 32-bit compressed offset of any read-only object is constant across all isolates in a process. +* **Deterministic Layout**: The `mksnapshot` tool deterministically creates a bit-identical read-only heap. +* **Two-Stage Build (Conceptual)**: To use these addresses in C++ code (`libv8`), V8 needs to know them at compile time. + 1. `mksnapshot` (or specialized generator tools) is run to generate the addresses and write them to configuration-specific headers (e.g., `src/roots/static-roots-intl-wasm.h`), which are included by `src/roots/static-roots.h` based on build flags. + 2. The main V8 binary is compiled, using these hardcoded offsets (e.g., `StaticReadOnlyRoot::kUndefinedValue`). + * *Note*: In practice, these generated headers are checked into the repository and only validated as part of normal compilation. If the read-only heap layout changes, the headers have to be regenerated with the `tools/dev/gen-static-roots.py` script. + +### Benefits +* **Faster Checks**: Instead of loading the address of `undefined` from the roots table, V8 can directly compare the compressed pointer to a constant (e.g., checking if it equals `StaticReadOnlyRoot::kUndefinedValue`). +* **Range Checks**: Common objects are grouped together. For example, all string maps are adjacent, allowing V8 to check if an object is a string by verifying if its map's address falls within a specific range. +* **Smaller Code**: Reduces the size of generated machine code by avoiding indirection through the roots table. + +## See Also +- [Objects and Maps](objects-and-maps.md) +- [Garbage Collection](garbage-collection.md) diff --git a/deps/v8/docs/heap/zone-allocator.md b/deps/v8/docs/heap/zone-allocator.md new file mode 100644 index 00000000000000..d5a148242421f8 --- /dev/null +++ b/deps/v8/docs/heap/zone-allocator.md @@ -0,0 +1,55 @@ +# Zone Allocator in V8 + +The Zone allocator is a region-based memory manager used in V8 to support fast allocation of small chunks of memory. Chunks allocated in a Zone cannot be deallocated individually. Instead, the Zone supports deallocating all chunks in one fast operation. + +This makes Zones ideal for holding temporary data structures that are needed only for a specific phase of execution, such as the Abstract Syntax Tree (AST) or compiler intermediate representations (IR), which can be discarded all at once after compilation is complete. + +Notably, object pointers within a Zone can be relied on to stay live and available after allocation for as long as the Zone is live. This allows easier definition of complex data structures without having to worry about reachability, reference counting, or clean teardown of individual elements. + +## How it Works + +The Zone allocator works by requesting large segments of memory from the OS or a memory pool and then satisfying allocation requests by simply moving a pointer within the current segment. + +### Segments + +A `Zone` maintains a linked list of `Segment`s. When a `Zone` is created, it doesn't allocate any memory immediately. The first allocation triggers the allocation of a segment. +Segments are requested via the `AccountingAllocator`. + +### Bump Pointer Allocation + +Within a segment, allocation is extremely fast. It is a "bump pointer" allocation: +1. Check if the requested size fits in the remaining space of the current segment. +2. If it fits, return the current position and "bump" the position pointer forward by the requested size. +3. If it doesn't fit, expand the zone by allocating a new segment. + +### Expansion Strategy + +When the current segment is full, the Zone calls `Expand` to get a new segment. +* The size of the new segment is typically double the size of the previous segment (high water mark strategy) to avoid excessive allocation overhead. +* The size is bounded by a minimum (`kMinimumSegmentSize`, typically 8KB) and a maximum (`kMaximumSegmentSize`, typically 32KB). +* New segments are prepended to the list of segments. + +## Key Classes + +* **`Zone`**: The main class representing the allocator. It provides `Allocate`, `New`, and `AllocateArray` methods. +* **`ZoneSnapshot`**: Stores the current allocation state of a Zone (position in the current segment and the list of segments). +* **`ZoneScope`**: A RAII-style class that takes a snapshot of a Zone on creation and restores the Zone to that state on destruction, effectively freeing all memory allocated during the scope. +* **`ZoneObject`**: A base class for objects that should be allocated in a Zone. It deletes the `delete` operator to prevent accidental individual deallocation. + * **CRITICAL NOTE**: Destructors of objects allocated in a Zone are **never** called when the Zone is discarded or reset. Objects allocated in a Zone must be robust against not being destructed (e.g., they must not own non-Zone resources like external heap memory, file handles, or standard containers like `std::vector` that manage their own memory). + +## Zone Containers + +To facilitate the use of Zones, V8 provides a set of containers that are specialized to use Zone allocation: +* **`ZoneVector`**: A custom vector implementation giving precise control over its implementation and performance. +* **`ZoneMap`**, **`ZoneSet`**, **`ZoneDeque`**, etc.: Wrappers around standard C++ containers specialized with a `ZoneAllocator`. + +These containers ensure that their internal nodes and backing stores are allocated within the Zone. + +## Usage in the Codebase + +The Zone allocator is used pervasively in the V8 compiler (`src/compiler/`). +* **Compilation Phases**: Many compiler phases create a local Zone for their duration and discard it afterwards. +* **Analysis Results**: Objects like `BytecodeAnalysis` are allocated in a Zone and contain Zone-based containers like `ZoneVector` and `ZoneMap` to store analysis data. +* **AST**: The parser allocates AST nodes in a Zone, which is then passed to the compiler and finally discarded. + +Note: The Zone implementation is inherently not thread-safe. diff --git a/deps/v8/docs/i18n.md b/deps/v8/docs/i18n.md new file mode 100644 index 00000000000000..efb51fee950be2 --- /dev/null +++ b/deps/v8/docs/i18n.md @@ -0,0 +1,39 @@ +--- +title: 'i18n support' +description: 'V8 optionally implements the ECMAScript 402 specification. The API is enabled by default, but can be turned off at compile time.' +--- +V8 optionally implements [the ECMAScript 402 specification](https://tc39.es/ecma402/). The API is enabled by default, but can be turned off at compile time. + +## Prerequisites + +The i18n implementation adds a dependency on ICU. As of v7.2, V8 requires at least ICU version 63. The exact dependency is specified in [V8’s `DEPS` file](https://crsrc.org/c/v8/DEPS). + +Run the following command to check out a suitable version of ICU into `third_party/icu`: + +```bash +gclient sync +``` + +See [“staying up to date”](/docs/source-code#staying-up-to-date) for more details. + +## Alternative ICU checkout + +You can check out the ICU sources at a different location and define the gyp variable `icu_gyp_path` to point at the `icu.gyp` file. + +## System ICU + +Last but not least, you can compile V8 against a version of ICU installed in your system. To do so, specify the GYP variable `use_system_icu=1`. If you also have `want_separate_host_toolset` enabled, the bundled ICU is still compiled to generate the V8 snapshot. The system ICU is only used for the target architecture. + +## Embedding V8 + +If you embed V8 in your application, but your application itself doesn’t use ICU, you need to initialize ICU before calling into V8 by executing: + +```cpp +v8::V8::InitializeICU(); +``` + +It is safe to invoke this method if ICU was not compiled in, then it does nothing. + +## Compiling without i18n support + +To build V8 without i18n support, use [`gn args`](/docs/build-gn#gn) to set `v8_enable_i18n_support = false` before compiling. diff --git a/deps/v8/docs/ide-setup.md b/deps/v8/docs/ide-setup.md new file mode 100644 index 00000000000000..3fc3a19b5da0fa --- /dev/null +++ b/deps/v8/docs/ide-setup.md @@ -0,0 +1,95 @@ +--- +title: 'GUI and IDE setup' +description: 'This document contains GUI and IDE-specific tips for working on the V8 code base.' +--- +The V8 source code can be browsed online with [Chromium Code Search](https://cs.chromium.org/chromium/src/v8/). + +This project’s Git repository may be accessed using many other client programs and plug-ins. See your client’s documentation for more information. + +## Visual Studio Code and clangd + +For instructions how to set up VSCode for V8, see this [document](https://docs.google.com/document/d/1BpdCFecUGuJU5wN6xFkHQJEykyVSlGN8B9o3Kz2Oes8/). This is currently (2021) the recommended setup. + +## Eclipse + +For instructions how to set up Eclipse for V8, see this [document](https://docs.google.com/document/d/1q3JkYNJhib3ni9QvNKIY_uarVxeVDiDi6teE5MbVIGQ/). Note: as of 2020, indexing V8 with Eclipse does not work well. + +## Visual Studio Code and cquery + +VSCode and cquery provide good code navigation capabilities. It offers “go to definition” as well as “find all references” for C++ symbols and works quite well. This section describes how to get a basic setup on a *nix system. + +### Install VSCode + +Install VSCode in your preferred way. The rest of this guide assumes that you can run VSCode from the command line via the command `code`. + +### Install cquery + +Clone cquery from [cquery](https://github.com/cquery-project/cquery) in a directory of your choice. We use `CQUERY_DIR="$HOME/cquery"` in this guide. + +```bash +git clone https://github.com/cquery-project/cquery "$CQUERY_DIR" +cd "$CQUERY_DIR" +git submodule update --init +mkdir build +cd build +cmake .. -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=release -DCMAKE_EXPORT_COMPILE_COMMANDS=YES +make install -j8 +``` + +If anything goes wrong, be sure to check out [cquery’s getting started guide](https://github.com/cquery-project/cquery/wiki). + +You can use `git pull && git submodule update` to update cquery at a later time (don't forget to rebuild via `cmake .. -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=release -DCMAKE_EXPORT_COMPILE_COMMANDS=YES && make install -j8`). + +### Install and configure cquery-plugin for VSCode + +Install the cquery extension from the marketplace in VSCode. Open VSCode in your V8 checkout: + +```bash +cd v8 +code . +``` + +Go to settings in VSCode, for example, via the shortcut Ctrl + ,. + +Add the following to your workspace configuration, replacing `YOURUSERNAME` and `YOURV8CHECKOUTDIR` appropriately. + +```json +"settings": { + "cquery.launch.command": "/home/YOURUSERNAME/cquery/build/release/bin/cquery", + "cquery.cacheDirectory": "/home/YOURUSERNAME/YOURV8CHECKOUTDIR/.vscode/cquery_cached_index/", + "cquery.completion.include.blacklist": [".*/.vscache/.*", "/tmp.*", "build/.*"], + […] +} +``` + +### Provide `compile_commands.json` to cquery + +The last step is to generate a compile_commands.json to cquery. This file will contain the specific compiler command lines used to build V8 to cquery. Run the following command in the V8 checkout: + +```bash +ninja -C out.gn/x64.release -t compdb cxx cc > compile_commands.json +``` + +This needs to be re-executed from time to time to teach cquery about new source files. In particular, you should always re-run the command after a `BUILD.gn` was changed. + +### Other useful settings + +The auto-closing of parenthesis in Visual Studio Code does not work that well. It can be disabled with + +```json +"editor.autoClosingBrackets": false +``` + +in the user settings. + +The following exclusion masks help avoid unwanted results when using search (Ctrl+Shift+F): + +```js +"files.exclude": { + "**/.vscode": true, // this is a default value +}, +"search.exclude": { + "**/out*": true, // this is a default value + "**/build*": true // this is a default value +}, +``` diff --git a/deps/v8/docs/index.md b/deps/v8/docs/index.md new file mode 100644 index 00000000000000..e23b7891adba9e --- /dev/null +++ b/deps/v8/docs/index.md @@ -0,0 +1,79 @@ +--- +title: 'Documentation' +description: 'Documentation for the V8 project.' +--- +V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and in Node.js, among others. + +This documentation is aimed at C++ developers who want to use V8 in their applications, as well as anyone interested in V8’s design and performance. This document introduces you to V8, while the remaining documentation shows you how to use V8 in your code and describes some of its design details, as well as providing a set of JavaScript benchmarks for measuring V8’s performance. + +## About V8 + +V8 implements ECMAScript and WebAssembly, and runs on Windows, macOS, and Linux systems that use x64, IA-32, or ARM processors. Additional systems (IBM i, AIX) and processors (MIPS, ppcle64, s390x) are externally maintained, see [ports](/docs/ports). V8 can be embedded into any C++ application. + +V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs. V8’s stop-the-world, generational, accurate garbage collector is one of the keys to V8’s performance. + +JavaScript is commonly used for client-side scripting in a browser, being used to manipulate Document Object Model (DOM) objects for example. The DOM is not, however, typically provided by the JavaScript engine but instead by a browser. The same is true of V8 — Google Chrome provides the DOM. V8 does however provide all the data types, operators, objects and functions specified in the ECMA standard. + +V8 enables any C++ application to expose its own objects and functions to JavaScript code. It’s up to you to decide on the objects and functions you would like to expose to JavaScript. + +## Documentation overview + +- [Building V8 from source](/docs/build) + - [Checking out the V8 source code](/docs/source-code) + - [Building with GN](/docs/build-gn) + - [Cross-compiling and debugging for ARM/Android](/docs/cross-compile-arm) + - [Cross-compiling for iOS](/docs/cross-compile-ios) + - [GUI and IDE setup](/docs/ide-setup) + - [Compiling on Arm64](/docs/compile-arm64) +- [Contributing](/docs/contribute) + - [Respectful code](/docs/respectful-code) + - [V8’s public API and its stability](/docs/api) + - [Becoming a V8 committer](/docs/become-committer) + - [Committer’s responsibility](/docs/committer-responsibility) + - [Blink web tests (a.k.a. layout tests)](/docs/blink-layout-tests) + - [Evaluating code coverage](/docs/evaluate-code-coverage) + - [Release process](/docs/release-process) + - [Design review guidelines](/docs/design-review-guidelines) + - [Implementing and shipping JavaScript/WebAssembly language features](/docs/feature-launch-process) + - [Checklist for staging and shipping of WebAssembly features](/docs/wasm-shipping-checklist) + - [Flake bisect](/docs/flake-bisect) + - [Handling of ports](/docs/ports) + - [Official support](/docs/official-support) + - [Merging & patching](/docs/merge-patch) + - [Node.js integration build](/docs/node-integration) + - [Reporting security bugs](https://chromium.googlesource.com/v8/v8/+/HEAD/SECURITY.md) + - [Running benchmarks locally](/docs/benchmarks) + - [Testing](/docs/test) + - [Triaging issues](/docs/triage-issues) +- Debugging + - [Arm debugging with the simulator](/docs/debug-arm) + - [Cross-compiling and debugging for ARM/Android](/docs/cross-compile-arm) + - [Debugging builtins with GDB](/docs/gdb) + - [Debugging over the V8 Inspector Protocol](/docs/inspector) + - [GDB JIT Compilation Interface integration](/docs/gdb-jit) + - [Investigating memory leaks](/docs/memory-leaks) + - [Stack trace API](/docs/stack-trace-api) + - [Using D8](/docs/d8) + - [V8 Tools](https://v8.dev/tools) +- Embedding V8 + - [Guide to embedding V8](/docs/embed) + - [Version numbers](/docs/version-numbers) + - [Built-in functions](/docs/builtin-functions) + - [i18n support](/docs/i18n) + - [Untrusted code mitigations](/docs/untrusted-code-mitigations) +- Under the hood + - [Ignition](/docs/ignition) + - [TurboFan](/docs/turbofan) + - [Torque user manual](/docs/torque) + - [Writing Torque built-ins](/docs/torque-builtins) + - [Writing CSA built-ins](/docs/csa-builtins) + - [Adding a new WebAssembly opcode](/docs/webassembly-opcode) + - [Maps, aka "Hidden Classes"](/docs/hidden-classes) + - [Slack Tracking - what is it?](/blog/slack-tracking) + - [WebAssembly compilation pipeline](/docs/wasm-compilation-pipeline) +- Writing optimizable JavaScript + - [Using V8’s sample-based profiler](/docs/profile) + - [Profiling Chromium with V8](/docs/profile-chromium) + - [Using Linux `perf` with V8](/docs/linux-perf) + - [Tracing V8](/docs/trace) + - [Using Runtime Call Stats](/docs/rcs) diff --git a/deps/v8/docs/inspector.md b/deps/v8/docs/inspector.md new file mode 100644 index 00000000000000..e714c2f0fdd580 --- /dev/null +++ b/deps/v8/docs/inspector.md @@ -0,0 +1,70 @@ +--- +title: 'Debugging over the V8 Inspector Protocol' +description: 'This page is intended to give embedders the basic tools they need to implement debugging support in V8.' +--- +V8 provides extensive debugging functionality to both users and embedders. Users will usually interact with the V8 debugger through the [Chrome DevTools](https://developer.chrome.com/devtools) interface. Embedders (including DevTools) need to rely directly on the [Inspector Protocol](https://chromedevtools.github.io/debugger-protocol-viewer/tot/). + +This page is intended to give embedders the basic tools they need to implement debugging support in V8. + +## Connecting to the Inspector + +V8’s [command-line debug shell `d8`](/docs/d8) includes a simple inspector integration through the [`InspectorFrontend`](https://crsrc.org/c/v8/src/d8/d8.cc?q=InspectorFrontend) and [`InspectorClient`](https://crsrc.org/c/v8/src/d8/d8.cc?q=InspectorClient). The client sets up a communication channel for messages sent from the embedder to V8: + +```cpp +static void SendInspectorMessage( + const v8::FunctionCallbackInfo& args) { + // [...] Create a StringView that Inspector can understand. + session->dispatchProtocolMessage(message_view); +} +``` + +Meanwhile, the frontend establishes a channel for messages sent from V8 to the embedder by implementing `sendResponse` and `sendNotification`, which then forward to: + +```cpp +void Send(const v8_inspector::StringView& string) { + // [...] String transformations. + // Grab the global property called 'receive' from the current context. + Local callback_name = + v8::String::NewFromUtf8(isolate_, "receive", v8::NewStringType::kNormal) + .ToLocalChecked(); + Local context = context_.Get(isolate_); + Local callback = + context->Global()->Get(context, callback_name).ToLocalChecked(); + // And call it to pass the message on to JS. + if (callback->IsFunction()) { + // [...] + MaybeLocal result = Local::Cast(callback)->Call( + context, Undefined(isolate_), 1, args); + } +} +``` + +## Using the Inspector Protocol + +Continuing with our example, `d8` forwards inspector messages to JavaScript. The following code implements a basic, but fully functional interaction with the Inspector through `d8`: + +```js +// inspector-demo.js +// Receiver function called by d8. +function receive(message) { + print(message) +} + +const msg = JSON.stringify({ + id: 0, + method: 'Debugger.enable', +}); + +// Call the function provided by d8. +send(msg); + +// Run this file by executing 'd8 --enable-inspector inspector-demo.js'. +``` + +## Further documentation + +A more fleshed-out example of Inspector API usage is available at [`test-api.js`](https://crsrc.org/c/v8/test/debugger/test-api.js), which implements a simple debugging API for use by V8’s test suite. + +V8 also contains an alternative Inspector integration at [`inspector-test.cc`](https://crsrc.org/c/v8/test/inspector/inspector-test.cc). + +The Chrome DevTools wiki provides [full documentation](https://chromedevtools.github.io/debugger-protocol-viewer/tot/) of all available functions. diff --git a/deps/v8/docs/interpreter/interpreter-ignition.md b/deps/v8/docs/interpreter/interpreter-ignition.md new file mode 100644 index 00000000000000..d538b4cee34453 --- /dev/null +++ b/deps/v8/docs/interpreter/interpreter-ignition.md @@ -0,0 +1,150 @@ +# Ignition: V8's Interpreter + +Ignition is V8's interpreter. It is the first tier in V8's execution pipeline, responsible for executing JavaScript code quickly after parsing without waiting for expensive compilation. For a high-level overview of Ignition, see the [V8 blog post](https://v8.dev/blog/ignition-interpreter). It was originally written using the backend of [TurboFan](../compiler/turbofan/compiler-turbofan.md). + +## Architecture & Design + +Ignition is designed as a high-performance interpreter with several key architectural choices: + +### 1. Register-Based with Accumulator +Unlike stack-based interpreters (like the JVM) that push and pop values from an expression stack, Ignition uses a **register file** mapped to the native stack. +* **Virtual Registers**: Function locals, parameters, and temporaries are mapped to fixed slots in the stack frame. +* **The Accumulator**: To keep bytecodes compact, V8 uses a dedicated **accumulator register**. Many operations implicitly read from or write to the accumulator, avoiding the need to specify register indices in the bytecode operands. + +### 2. Fixed-Size Stack Frame +Ignition uses a fixed-size stack frame for a given function, calculated at compile time by the `BytecodeGenerator`. The frame layout (defined in `src/execution/frame-constants.h`) includes (from high to low addresses): +* **Parameters**: Passed by the caller (negative offsets from FP). +* **Fixed Header**: Return address, saved frame pointer (FP points here), [Constant Pool] (optional), Context, JSFunction, and argument count (argc). +* **Unoptimized Header**: + * `BytecodeArray`: Pointer to the bytecode being executed. + * `offset / cell`: The current bytecode offset or FeedbackCell. + * `FBV`: Pointer to the `FeedbackVector`. +* **Register File**: The virtual registers used by the function (positive offsets from FP). + +### 3. Threaded Dispatch +Ignition does not use a centralized `switch` statement in a loop for interpretation. Instead, it uses **threaded dispatch**: +* Every bytecode handler is a standalone chunk of machine code. +* At the end of each handler, it fetches the next bytecode, looks up its handler address in a **dispatch table** (stored in a dedicated CPU register for fast access), and directly jumps to it. +* This minimizes branch mispredictions compared to a giant switch loop. + +### 4. Wide and Extra-Wide Bytecodes +To keep the common case compact, standard bytecodes use 8-bit operands (supporting up to 256 registers or constant pool indices). However, large functions may exceed these limits. +* V8 solves this using **prefix bytecodes**: `Wide` and `ExtraWide`. +* If a bytecode needs to reference a register index `> 255`, the generator emits a `Wide` prefix followed by the bytecode. The `Wide` prefix signals the interpreter to read 16-bit operands for the next instruction. +* `ExtraWide` allows for 32-bit operands. + +### 5. The Constant Pool +Complex objects, large integers, and strings are not embedded directly in the bytecode stream. Instead, they are stored in a `FixedArray` called the **Constant Pool** attached to the `BytecodeArray`. Bytecodes reference constants via their index in this pool. The `ConstantArrayBuilder` manages this, placing constants in 8-bit, 16-bit, or 32-bit slices based on frequency and size, coordinating with Wide/ExtraWide bytecodes. + +## Bytecode Example + +To understand how Ignition executes code, let's look at a concrete JavaScript function and the bytecode V8 generates for it. + +```javascript +function foo(obj, x) { + if (x > 0) { + return obj.y + x; + } + return 0; +} +``` + +Here is the generated bytecode (simplified for readability): + +```text + 0 : LdaZero // Accumulator = 0 + 1 : TestGreaterThan a1, [0] // Compare a1 (x) with accumulator (0) + 5 : JumpIfFalse [13] (at 18) // If false, jump to offset 18 + 7 : GetNamedProperty a0, [0], [1] // Load obj.y into accumulator (a0 is obj, [0] is name "y") + 11 : Star0 // Store accumulator (obj.y) in register r0 + 12 : Ldar a1 // Load a1 (x) into accumulator + 14 : Add r0, [0] // Add r0 (obj.y) to accumulator (x) + 17 : Return // Return accumulator + 18 : LdaZero // Accumulator = 0 + 19 : Return // Return accumulator +``` + +### Explanation of Bytecodes: +* **`LdaZero`**: Loads the constant `0` into the accumulator. +* **`TestGreaterThan a1, [0]`**: Compares the value in register `a1` (parameter `x`) with the accumulator (`0`). The `[0]` is a feedback slot index for the Inline Cache. +* **`JumpIfFalse [13]`**: If the previous test was false, jumps `13` bytes forward to offset `18`. +* **`GetNamedProperty a0, [0], [1]`**: Loads a named property from object in `a0` (`obj`). `[0]` is the index in the constant pool for the string `"y"`. `[1]` is the feedback slot. The result is placed in the accumulator. +* **`Star0`**: Stores the value in the accumulator into virtual register `r0`. +* **`Ldar a1`**: Loads the value from register `a1` (`x`) into the accumulator. +* **`Add r0, [0]`**: Adds the value in `r0` to the accumulator. `[0]` is the feedback slot. +* **`Return`**: Returns the value currently in the accumulator. + +## Bytecode Generation + +The process of turning JavaScript source code into bytecode is handled by the `BytecodeGenerator` in `src/interpreter/bytecode-generator.cc`. + +### The AST Visitor + +`BytecodeGenerator` is an Abstract Syntax Tree (AST) visitor. It inherits from `AstVisitor` and implements `Visit...` methods for all AST node types (e.g., `VisitBlock`, `VisitBinaryOperation`, `VisitCall`). + +When `GenerateBytecode` is called: +1. It traverses the AST starting from the root function literal. +2. For each node, it calls the corresponding `Visit` method. +3. The `Visit` method emits bytecodes using the `BytecodeArrayBuilder`. + +### Registers and The Accumulator + +* **Register Allocation**: The generator manages a set of virtual registers. It uses a `BytecodeRegisterAllocator` to allocate and free registers as it evaluates expressions. +* **Accumulator Optimization**: The generator tries to keep values in the accumulator as much as possible to reduce bytecode size. For example, when evaluating `a + b`: + 1. Visit `a` for accumulator value (loads `a` into accumulator). + 2. Store accumulator to a temporary register `r0`. + 3. Visit `b` for accumulator value (loads `b` into accumulator). + 4. Emit `Add r0`, which adds `r0` (containing `a`) to the accumulator (containing `b`). + +### Control Flow + +* **Labels**: For jumps (loops, conditionals), the generator uses `BytecodeLabel` to mark jump targets. The `BytecodeArrayWriter` patches these labels with actual offsets later. +* **Scopes**: The generator tracks the current lexical scope and emits bytecodes to create and link context objects (`LdaContext`, `StaContext`) when entering blocks with new variables. + +--- + +## Optimizations + +* **Star Lookahead**: Ignition includes optimizations like `StarDispatchLookahead`. It checks if the next bytecode is a short `Star` bytecode (storing accumulator to register). If so, it can inline the effect to avoid a full dispatch. + +## Example Bytecodes + +Here are a few examples of Ignition bytecodes (defined in `src/interpreter/bytecodes.h`): + +* `LdaSmi `: Load a Small Integer immediate into the accumulator. +* `Star `: Store the value in the accumulator into register ``. +* `Ldar `: Load the value from register `` into the accumulator. +* `Add , [slot]`: Add the value in register `` to the accumulator, updating feedback in the specified slot. +* `CallProperty , , , [slot]`: Call a property on an object. + +## Interaction with Feedback + +As Ignition executes bytecode, it collects type feedback for operations that can benefit from optimization (like property accesses and arithmetic). + +* The bytecode contains indices to slots in the `FeedbackVector`. +* Handlers write feedback to these slots (e.g., recording the `Map` of an object seen at a property load). +* This feedback is later used by Maglev and TurboFan to generate optimized code. + +## File Structure +* `src/interpreter/interpreter.cc`: Setup code and dispatch table initialization. +* `src/interpreter/interpreter-assembler.cc`: Contains the actual bytecode handler implementations (using CodeStubAssembler). +* `src/interpreter/bytecode-generator.cc`: Generates bytecode from AST. +* `src/interpreter/bytecodes.h`: Defines all bytecodes and their properties. + +## External Resources + +### Talks +- [V8: Hooking up the Ignition to the Turbofan](https://docs.google.com/presentation/d/1chhN90uB8yPaIhx_h2M3lPyxPgdPmkADqSNAoXYQiVE/edit) +- [Ignition: jump-starting an interpreter for V8](https://docs.google.com/presentation/d/1HgDDXBYqCJNasBKBDf9szap1j4q4wnSHhOYpaNy5mHU/edit#slide=id.g1357e6d1a4_0_58) +- [Ignition: an interpreter for V8](https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit) ([video](https://youtu.be/r5OWCtuKiAk)) + +### Articles +- [Understanding V8’s bytecode](https://medium.com/dailyjs/understanding-v8s-bytecode-317d46c94775) + +### Design Docs +- [Ignition design document](https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/edit?ts=56f27d9d#heading=h.6jz9dj3bnr8t) +- [Register equivalence optimization](https://docs.google.com/document/d/1wW_VkkIwhAAgAxLYM0wvoTEkq8XykibDIikGpWH7l1I/edit?ts=570d7131#heading=h.6jz9dj3bnr8t) + +## See Also +- [Hidden Classes and Inline Caches](../runtime/hidden-classes-and-ics.md) +- [Function Architecture](../runtime/function-architecture.md) diff --git a/deps/v8/docs/javascript-overview.md b/deps/v8/docs/javascript-overview.md new file mode 100644 index 00000000000000..ea64ec409ae3e7 --- /dev/null +++ b/deps/v8/docs/javascript-overview.md @@ -0,0 +1,104 @@ +# JavaScript Overview for V8 Developers + +This document provides a high-level overview of how JavaScript works, focusing on concepts that are relevant for understanding V8's implementation. + +## Primitives vs. Objects + +JavaScript has two main categories of values: + +### 1. Primitives +Immutable values that are passed by value. +* `undefined`, `null`, `boolean` (`true`/`false`), `number`, `string`, `bigint`, `symbol`. (Spec names are capitalized, but JS `typeof` returns lowercase strings). +* In V8, small integers (Smis) are stored directly in the pointer word, while other primitives are allocated on the heap (e.g., `HeapNumber`, `String`). + +### 2. Objects +Mutable collections of properties, passed by reference. +* Any value that is not a primitive is an object (including arrays and functions). +* In V8, objects are represented by `JSObject` and its subclasses. +* **Note**: JS also has primitive wrapper objects (e.g., `new String('foo')`), which are actual objects and not primitives. Be careful not to confuse them with the primitive values! + +## How V8 implements prototypes + +JavaScript uses a **prototypal inheritance** model. Every object has a hidden link to another object called its **prototype** (internal `[[Prototype]]`). + +### Prototype Chain +* When you access a property on an object, JavaScript first looks for it on the object itself. +* If not found, it looks at the object's prototype, and then the prototype's prototype, forming a **prototype chain**. +* The chain ends when it reaches `null` (typically `Object.prototype.__proto__` is `null`). + +### `Foo.prototype` vs `foo.__proto__` +* `Foo.prototype` is a property of the **constructor function** `Foo`. It is the object that will be used as the prototype for instances created with `new Foo()`. +* `foo.__proto__` is a property of the **instance** `foo`. It points to the prototype object that `foo` inherited from. +* If `foo = new Foo()`, then `foo.__proto__ === Foo.prototype`. + +```dot +digraph G { + rankdir=TB; + node [shape=record]; + edge []; + + Foo [label="Constructor: Foo"]; + Foo_Proto [label="Foo.prototype"]; + foo [label="Instance: foo"]; + Obj_Proto [label="Object.prototype"]; + null_node [label="null"]; + + Foo -> Foo_Proto [label=".prototype"]; + Foo -> foo [label="new Foo", style=dashed]; + foo -> Foo_Proto [label="[[Prototype]]"]; + Foo_Proto -> Obj_Proto [label="[[Prototype]]"]; + Obj_Proto -> null_node [label="[[Prototype]]"]; +} +``` + +### `__proto__` and V8 Implementation +* `__proto__` is an accessor property (getter/setter) on `Object.prototype` that exposes the internal prototype link. +* Modern JavaScript recommends using `Object.getPrototypeOf()` and `Object.setPrototypeOf()` instead of `__proto__`. +* In V8, the prototype is stored in the `Map` of the object. Changing the prototype of an object changes its map! + +## ES6 Classes + +ES6 classes are primarily **syntactic sugar** over JavaScript's existing prototype-based inheritance. + +```javascript +class Animal { + constructor(name) { + this.name = name; + } + speak() { + console.log(`${this.name} makes a noise.`); + } +} + +class Dog extends Animal { + speak() { + console.log(`${this.name} barks.`); + } +} +``` + +Under the hood, this is equivalent to: + +```javascript +function Animal(name) { + this.name = name; +} +Animal.prototype.speak = function() { + console.log(this.name + ' makes a noise.'); +}; + +function Dog(name) { + Animal.call(this, name); +} +Dog.prototype = Object.create(Animal.prototype); +Dog.prototype.constructor = Dog; +Dog.prototype.speak = function() { + console.log(this.name + ' barks.'); +}; +``` + + + +## File Structure +* `src/objects/js-objects.h`: Definitions for JavaScript objects. +* `src/objects/map.h`: Definitions for Maps (hidden classes) which store prototype links. diff --git a/deps/v8/docs/linux-perf.md b/deps/v8/docs/linux-perf.md new file mode 100644 index 00000000000000..0bc726a28d5a2f --- /dev/null +++ b/deps/v8/docs/linux-perf.md @@ -0,0 +1,123 @@ +--- +title: 'V8’s Linux `perf` integration' +description: 'This document explains how to analyze the performance of V8’s JITted code with the Linux `perf` tool.' +--- + +V8 has built-in support for the Linux `perf` tool. It is enabled by the +`--perf-prof` command-line options. +V8 writes out performance data during execution into a file that can be used to +analyze the performance of V8’s JITted code (including JS-function names) with +the Linux `perf` tool. + +## Requirements + +- `linux-perf` version 5 or higher (previous versions don't have JIT support). +- Build V8/Chrome with `enable_profiling=true` for better symbolized C++ code. + +## Building V8 + +To use V8’s integration with Linux perf you need to build it with the +`enable_profiling = true` gn flag: + +```bash +echo 'enable_profiling = true' >> out/x64.release/args.gn +autoninja -C out/x64.release +``` + +## Profiling `d8` with [`linux-perf-d8.py`](https://source.chromium.org/search?q=linux-perf-d8.py) + +After building `d8`, you can start using linux perf: + +```bash +tools/profiling/linux-perf-d8.py out/x64.release/d8 path/to/test.js; +``` + +A more complete example: + +```bash +echo '(function f() { + var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; + })();' > test.js; + +# Use custom V8 flags and a separate output dir for less clutter: +mkdir perf_results +tools/profiling/linux-perf-d8.py --perf-data-dir=perf_results \ + out/x64.release/d8 --expose-gc --allow-natives-syntax test.js; + +# Fancy UI (`-flame` is googler-only, use `-web` as a public alternative): +pprof -flame perf_results/XXX_perf.data.jitted; +# Terminal-based tool: +perf report -i perf_results/XXX_perf.data.jitted; +``` + +Check `linux-perf-d8.py --help` for more details. Note that you can use all +`d8` flags after the d8 binary argument. + +## Profiling Chrome or content_shell with crossbench + +We recommend using [crossbench](https://chromium.googlesource.com/crossbench) +for profiling Chrome on all platforms (which uses linux-perf on linux). + +```bash +$CHROME_CHECKOUT/src/tools/perf/cb loading \ + --browser=out/x64.release/chrome \ + --probe=profiling \ + --url=http://test.com +``` + +## Profiling Chrome or content_shell on Linux with [linux-perf-chrome.py](https://source.chromium.org/search?q=linux-perf-chrome.py) + +1. You can use the [linux-perf-chrome.py](https://source.chromium.org/search?q=linux-perf-chrome.py) + script to profile Chrome. Make sure to add the [required chrome gn flags](https://chromium.googlesource.com/chromium/src/+/main/docs/profiling.md#General-checkout-setup) + to get proper C++ symbols. + +2. Once your build is ready, you can profile a website with both full symbols + for C++ and JS code. + + ```bash + mkdir perf_results; + tools/profiling/linux-perf-chrome.py out/x64.release/chrome \ + --perf-data-dir=perf_results --timeout=30 + ``` + +3. Navigate to your website and then close the browser (or wait for the + `--timeout` to complete). + +4. After quitting the browser, `linux-perf-chrome.py` will post-process the + files and show a list with a result file for each renderer process: + + ``` + chrome_renderer_1583105_3.perf.data.jitted 19.79MiB + chrome_renderer_1583105_2.perf.data.jitted 8.59MiB + chrome_renderer_1583105_4.perf.data.jitted 0.18MiB + chrome_renderer_1583105_1.perf.data.jitted 0.16MiB + ``` + +## Exploring linux-perf results + +Finally, you can use the Linux `perf` tool to explore the profile of a `d8` or +Chrome renderer process: + +```bash +perf report -i perf_results/XXX_perf.data.jitted +``` + +You can also use [pprof](https://github.com/google/pprof) to generate more +visualizations: + +```bash +# Note: `-flame` is google-only, use `-web` as a public alternative: +pprof -flame perf_results/XXX_perf.data.jitted; +``` + +### V8 linux-perf Flags + +[`--perf-prof`](https://source.chromium.org/search?q=FLAG_perf_prof) is used on +the V8 command-line to record performance samples in JIT code. + +[`--interpreted-frames-native-stack`](https://source.chromium.org/search?q=FLAG_interpreted_frames_native_stack) +is used to create different entry points (copied versions of +InterpreterEntryTrampoline) for interpreted functions so they can be +distinguished by `perf` based on the address alone. Since the +InterpreterEntryTrampoline has to be copied, this comes at a slight performance +and memory regression. diff --git a/deps/v8/docs/memory-leaks.md b/deps/v8/docs/memory-leaks.md new file mode 100644 index 00000000000000..86382a0e845530 --- /dev/null +++ b/deps/v8/docs/memory-leaks.md @@ -0,0 +1,53 @@ +--- +title: 'Investigating memory leaks' +description: 'This document provides guidance on investigating memory leaks in V8.' +--- +If you’re investigating a memory leak and wonder why an object is not garbage-collected, you can use `%DebugTrackRetainingPath(object)` to print the actual retaining path of the object on each GC. + +This requires `--allow-natives-syntax --track-retaining-path` run-time flags and works both in release and debug modes. More info in the CL description. + +Consider the following `test.js`: + +```js +function foo() { + const x = { bar: 'bar' }; + %DebugTrackRetainingPath(x); + return () => { return x; } +} +const closure = foo(); +gc(); +``` + +Example (use debug mode or `v8_enable_object_print = true` for much more verbose output): + +```bash +$ out/x64.release/d8 --allow-natives-syntax --track-retaining-path --expose-gc test.js +################################################# +Retaining path for 0x245c59f0c1a1: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 6: 0x245c59f0c1a1 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 5: 0x245c59f0c169 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 4: 0x245c59f0c219 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 3: 0x1fbb02e2d679 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 2: 0x245c59f0c139 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Distance from root 1: 0x1fbb02e03d91 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Root: (Isolate) +------------------------------------------------- +``` + +## Debugger support + +While in a debugger session (e.g. `gdb`/`lldb`), and assuming you passed the above flags to the process (i.e. `--allow-natives-syntax --track-retaining-path`), you may be able to `print isolate->heap()->PrintRetainingPath(HeapObject*)` on an object of interest. diff --git a/deps/v8/docs/merge-patch.md b/deps/v8/docs/merge-patch.md new file mode 100644 index 00000000000000..5152282dfe2de4 --- /dev/null +++ b/deps/v8/docs/merge-patch.md @@ -0,0 +1,81 @@ +--- +title: 'Merging & patching' +description: 'This document explains how to merge V8 patches to a release branch.' +--- +If you have a patch to the `main` branch (e.g. an important bug fix) that needs to be merged into one of the release V8 branches (refs/branch-heads/12.5), read on. + +The following examples use a branched 12.3 version of V8. Substitute `12.3` with your version number. Read the documentation on [V8’s version numbering](/docs/version-numbers) for more information. + +An associated issue on V8’s issue tracker is **mandatory** if a patch is merged. This helps with keeping track of merges. + +## What qualifies a merge candidate? + +- The patch fixes a *severe* bug (in order of importance): + 1. security bug + 1. stability bug + 1. correctness bug + 1. performance bug +- The patch does not alter APIs. +- The patch does not change behavior present before branch cut (except if the behavior change fixes a bug). + +More information can be found on the [relevant Chromium page](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/process/merge_request.md). When in doubt, send an email to . + +## The merge process + +The merge process in the V8 tracker is driven by Attributes. Therefore please set the 'Merge-Request' on to the relevant Chrome Milestone. In case the merge is only affecting a V8 [port](https://v8.dev/docs/ports) please set the HW attribute accordingliy. E.g: + +``` +Merge-Request: 123 +HW: MIPS,LoongArch64 +``` + +once reviewed, this will be adjusted during the review to: + +``` +Merge: Approved-123 +or +Merge: Rejected-123 +``` + +After the CL landed, this will be adjusted one more time to: + +``` +Merge: Merged-123, Merged-12.3 +``` + +## How to check if a commit was already merged/reverted/has Canary coverage + +Use [chromiumdash](https://chromiumdash.appspot.com/commit/) to verify if the relevant CL has Canary coverage. + + +On top the **Releases** section should show a Canary. + +## How to create the merge CL + +### Option 1: Using [gerrit](https://chromium-review.googlesource.com/) - Recommended + + +1. Open the CL you want to back-merge. +1. Select "Cherry pick" from the extended menu (three vertical dots in the upper right corner). +1. Enter "refs/branch-heads/*XX.X*" as destination branch (replace *XX.X* by the proper branch). +1. Modify the commit message and prefix the title with "Merged: ". +1. In case of merge conflict, please also go ahead and create the CL. To resolve conflicts (if any) - either using the gerrit UI or you can easily pull the patch locally by using the "download patch" command from the menu (three vertical dots in the upper right corner). +1. Send out for review. + +### Option 2: Using the automated script + +Let’s assume you’re merging revision af3cf11 to branch 12.2 (please specify full git hashes - abbreviations are used here for simplicity). + +``` +https://crsrc.org/c/v8/tools/release/merge_to_branch_gerrit.py --branch 12.3 -r af3cf11 +``` + + +### After landing: Observe the [branch waterfall](https://ci.chromium.org/p/v8) + +If one of the builders is not green after handling your patch, revert the merge immediately. A bot (`AutoTagBot`) takes care of the correct versioning after a 10-minute wait. + +## Patching a version used on Canary/Dev + +In case you need to patch a Canary/Dev version (which should not happen often), cc vahl@ or machenbach@ on the issue. Googlers: please check out the [internal site](http://g3doc/company/teams/v8/patching_a_version) before creating the CL. + diff --git a/deps/v8/docs/node-integration.md b/deps/v8/docs/node-integration.md new file mode 100644 index 00000000000000..c5ba88f6c59368 --- /dev/null +++ b/deps/v8/docs/node-integration.md @@ -0,0 +1,71 @@ +--- +title: 'What to do if your CL broke the Node.js integration build' +description: 'This document explains what to do if your CL broke the Node.js integration build.' +--- +[Node.js](https://github.com/nodejs/node) uses V8 stable or beta. For additional integration, the V8 team builds Node with V8's [main branch](https://chromium.googlesource.com/v8/v8/+/refs/heads/main), i.e., with a V8 version from today. We provide an integration bot for [Linux](https://ci.chromium.org/p/node-ci/builders/ci/Node-CI%20Linux64), while [Windows](https://ci.chromium.org/p/node-ci/builders/ci/Node-CI%20Win64) and [Mac](https://ci.chromium.org/p/node-ci/builders/ci/Node-CI%20Mac64) are in the works. + +If the [`node_ci_linux64_rel`](https://ci.chromium.org/p/node-ci/builders/try/node_ci_linux64_rel) bot fails on the V8 commit queue, there is either a legitimate problem with your CL (fix it) or [Node](https://github.com/v8/node/) must be modified. If the Node tests failed, search for “Not OK” in the log files. **This document describes how to reproduce the problem locally and how to make changes to [V8’s Node fork](https://github.com/v8/node/) if your V8 CL causes the build to fail.** + +## Source + +Follow the [instructions](https://chromium.googlesource.com/v8/node-ci) at the node-ci repository to check out source. + +## Test changes to V8 + +V8 is set up as a DEPS dependency of node-ci. You may want to apply changes to V8 for testing or to reproduce failures. To do so, add your main V8 checkout as remote: + +```bash +cd v8 +git remote add v8 /.git +git fetch v8 +git checkout v8/ +cd .. +``` + +Remember to run gclient hooks before compiling. + +```bash +gclient runhooks +JOBS=`nproc` make test +``` + +## Make changes to Node.js + +Node.js is also set up as a `DEPS` dependency of node-ci. You may want to apply changes to Node.js to fix breakages that V8 changes may cause. V8 tests against a [fork of Node.js](https://github.com/v8/node). You need a GitHub account to make changes to that fork. + +### Get the Node sources + +Fork [V8’s Node.js repository on GitHub](https://github.com/v8/node/) (click the fork button) unless you already did previously. + +Add your both your fork and V8’s fork as remotes to the existing checkout: + +```bash +cd node +git remote add v8 http://github.com/v8/node +git remote add git@github.com:/node.git +git fetch v8 +git checkout v8/node-ci- +export BRANCH_NAME=`date +"%Y-%m-%d"`_fix_name +git checkout -b $BRANCH_NAME +``` + +> **Note** `` is the date we sync’ed with upstream Node.js. Choose the latest date. + +Make your changes to the Node.js checkout, and commit them. Then push the changes to GitHub: + +```bash +git push $BRANCH_NAME +``` + +And create a pull request against the branch `node-ci-`. + + +Once the pull request has been merged to V8’s fork of Node.js, you need to update node-ci’s `DEPS` file, and create a CL. + +```bash +git checkout -b update-deps +gclient setdep --var=node_revision= +git add DEPS +git commit -m 'Update Node' +git cl upload +``` diff --git a/deps/v8/docs/objects/descriptor-and-transition-arrays.md b/deps/v8/docs/objects/descriptor-and-transition-arrays.md new file mode 100644 index 00000000000000..b3ce409753550a --- /dev/null +++ b/deps/v8/docs/objects/descriptor-and-transition-arrays.md @@ -0,0 +1,133 @@ +# Descriptor and Transition Arrays in V8 + +To save memory and enable fast property access, V8 shares structural information between objects. This is achieved using `DescriptorArray` and `TransitionArray`, which are linked from an object's `Map`. + +## Descriptor Array Sharing and Ownership + +A `DescriptorArray` holds the property descriptors for a `Map`. It describes the names, attributes, and locations of properties. + +### Layout +`DescriptorArray` is a custom array-like structure (inheriting from `HeapObject`). It does not use a standard `FixedArray` for its entries to optimize for performance and memory. + +Each entry in the array consists of 3 fields, making the entry size 3: +* **Key** (Index 0): The property name (a `Name`). +* **Details** (Index 1): Property details encoded as a `Smi`. This includes property attributes (e.g., ReadOnly, DontEnum), kind (Data or Accessor), and location (Field or Descriptor). It also contains a pointer used for sorting. +* **Value** (Index 2): This holds either: + * A `FieldType` (wrapped as a `MaybeObject`) if the property is stored in a field. + * The constant value if it is a constant property. + * An accessor object if it is an accessor. + +### Sharing Mechanism +Instead of every `Map` having its own `DescriptorArray`, maps that are part of the same transition tree share a single `DescriptorArray`. + +* **Prefix Sharing**: A `Map` only "sees" a prefix of the shared `DescriptorArray`. The number of properties valid for a specific map is determined by its `NumberOfOwnDescriptors()`. +* **Example**: + * `Map A` has property `x`. `NumberOfOwnDescriptors() = 1`. + * `Map B` (transitioned from A) adds property `y`. `NumberOfOwnDescriptors() = 2`. + * Both `Map A` and `Map B` point to the *same* `DescriptorArray` containing `[x, y]`. `Map A` only looks at the first element, while `Map B` looks at both. + +### Ownership (`owns_descriptors`) +To manage memory and avoid conflicting modifications, only one `Map` in a sharing group "owns" the `DescriptorArray`. This is tracked by the `owns_descriptors` bit in the `Map`. + +* Usually, the most specific map (the leaf in the transition tree) owns the array. +* When a new property is added, creating a new map, ownership is typically transferred to the new map. + +### Splitting the Array +If a map needs to be modified in a way that doesn't fit the linear transition model (e.g., an elements kind transition or a prototype transition), V8 may need to **split** the descriptor array: +* If the map does *not* own the descriptors, it cannot modify them in place. +* V8 will create a *copy* of the `DescriptorArray` up to the map's `NumberOfOwnDescriptors()`. +* The new map will own this new copy, detaching it from the original sharing group. + +## Transition Arrays + +A `TransitionArray` holds transitions from one `Map` to another, forming the edges of the transition tree. + +### Purpose +When a property is added or attributes change, V8 searches the current map's `TransitionArray` for a matching transition. If found, the object takes the target map. If not, a new map is created and a new transition is inserted. + +### Layout +`TransitionArray` is a `WeakFixedArray`. +* **Header**: Contains: + * `[0]`: Pointer to prototype transitions (or Smi 0). + * `[1]`: Pointer to side-step transitions (or Smi 0). + * `[2]`: Number of transitions (as a Smi). +* **Elements**: Pairs of `[Key, TargetMap]`. The `TargetMap` is a **weak reference**, allowing the GC to collect maps that are no longer reachable, automatically pruning the transition tree. + +### Side-Step Transitions +Side-step transitions are special edges in the transition tree used for operations that bypass standard property addition, such as `Object.assign()` or object cloning. They allow V8 to quickly find the target map for these operations if they have been performed before. + +## Detaching from the Transition Tree + +Not all maps are connected to a transition tree. A map can be **detached**. + +### What is a Detached Map? +A map is considered detached if it is not reachable via transitions from a root map. +In V8, `Map::IsDetached()` returns true if: +1. It is a **prototype map**. Prototype maps are often isolated to prevent pollution of the main transition tree. +2. It is a standard `JS_OBJECT_TYPE` map that has properties (`NumberOfOwnDescriptors() > 0`) but its back pointer is `Undefined`. + +### When does detaching happen? +* **OMIT_TRANSITION**: When copying a map, V8 can be instructed to omit creating a transition. The new map will have no back pointer and will be detached. +* **Immutable Prototypes**: Maps for objects with immutable prototypes (like the global object) are not cached in the transition tree to save memory. +* **Forced Splits**: As mentioned in descriptor sharing, when a non-leaf map needs a new descriptor array, it creates a detached copy. +* **GC Pruning**: Since transitions are weak, if a target map is only reachable through the transition array and no objects use it, the GC will clear the transition, effectively detaching the subtree. + +## Summary Diagram + +```javascript +var a = {}; +a.x = 1; + +var b = {}; +b.x = 1; +b.y = 2; + +var c = {}; +c.x = 1; +c.z = 3; +``` + + +```dot +digraph G { + rankdir=TB; + newrank=true; + node [shape=record]; + edge []; + + subgraph Objects { + a [label="{a | 1}"]; + b [label="{b | 1 | 2}"]; + c [label="{c | 1 | 3}"]; + } + + subgraph Maps { + RootMap [label="Root Map\n(owns=false)"]; + MapX [label="Map (x)\n(owns=false)"]; + { + rank="same" + MapY [label="Map (x,y)\n(owns=true)"]; + MapZ [label="Map (x,z)\n(owns=true)"]; + } + DescsXY [label="{DescriptorArray | x | y}"]; + DescsXZ [label="{DescriptorArray | x | z}"]; + + RootMap -> MapX [label="Add 'x'", style=dashed]; + MapX -> MapY [label="Add 'y'", style=dashed]; + + RootMap -> DescsXY; + MapX -> DescsXY; + MapY -> DescsXY; + + MapX -> MapZ [label="Add 'z'", style=dashed]; + MapZ -> DescsXZ; + } + + a->MapX; + b->MapY; + c->MapZ; +} +``` + +## See Also +- [Objects and Maps](../heap/objects-and-maps.md) diff --git a/deps/v8/docs/objects/fields-and-elements.md b/deps/v8/docs/objects/fields-and-elements.md new file mode 100644 index 00000000000000..6a1a29bb4b3ea0 --- /dev/null +++ b/deps/v8/docs/objects/fields-and-elements.md @@ -0,0 +1,147 @@ +# Field Representations and Elements Kinds + +This document explains how V8 optimizes object properties and array elements by specializing their storage representation based on the types of values they contain. + +## Overview + +JavaScript is dynamically typed, but V8 attempts to treat objects as if they had static types to improve performance. Two key mechanisms for this are **Field Representations** (for named properties) and **Elements Kinds** (for indexed properties/array elements). + +--- + +## Field Representations + +When properties are stored in the **Descriptor Array** of a Map, V8 tracks the **Representation** of each data property. This allows V8 to avoid boxing numbers or storing full pointers when not necessary. + +### Representation Types +Defined in `src/objects/property-details.h`, the main representations are: + +* **`kSmi`**: The property always holds a Small Integer (Smi). Stored directly in the object without allocation. +* **`kDouble`**: The property holds a double-precision float. It is stored as a boxed `HeapNumber` (in-object unboxing is no longer supported). Tracking this representation allows V8 to avoid type checks. Furthermore, the boxed number is allowed to be mutated in-place on store (normally `HeapNumber`s are immutable), avoiding allocation. However, reading it requires a copy unless in optimized code that can handle raw float64 values. + * *Note on Size*: Fields can be double-sized (even without pointer compression), in which case they take up 8 bytes but are still referenced by a single descriptor. +* **`kHeapObject`**: The property always holds a reference to a heap object. It can store a specific "field type" in the property descriptor (i.e., the expected `Map` of the field), or it can be a generic non-Smi `HeapObject`. +* **`kWasmValue`**: Used for WasmObject fields. It indicates that the actual field type information must be taken from the Wasm RTT (Runtime Type) associated with the map. +* **`kTagged`**: The most general representation. It can hold any valid JavaScript value (Smi or HeapObject). +* **`kNone`**: Uninitialized property. + +### PropertyDetails +Every property has an associated `PropertyDetails` value (a 32-bit integer) that packs: +* **Kind**: Data or Accessor. +* **Location**: Field (in object or property array) or Descriptor (stored in the Map itself). +* **Constness**: Mutable or Const. +* **Representation**: As listed above. + +#### Deep Dive: PropertyDetails Bit Layout + +V8 packs this information tightly into a 32-bit integer. The layout differs between **fast mode** (using descriptor arrays) and **slow mode** (dictionary properties). + +**For Fast Mode Properties:** +* **Kind** (Data vs Accessor): 1 bit +* **Constness** (Mutable vs Const): 1 bit +* **Attributes** (ReadOnly, DontEnum, DontDelete): 3 bits +* **Location** (Field vs Descriptor): 1 bit +* **Representation** (None, Smi, Double, HeapObject, Tagged): 3 bits +* **Descriptor Pointer**: 10 bits (index in the descriptor array) +* **Field Offset In Words**: 11 bits (offset in storage header) +* **In-Object**: 1 bit (whether stored directly in JSObject) + +**For Dictionary Mode Properties:** +* **Kind**: 1 bit +* **Constness**: 1 bit +* **Attributes**: 3 bits +* **PropertyCellType**: 3 bits (Mutable, Undefined, Constant, ConstantType, InTransition, NoCell) +* **Dictionary Storage Index**: 23 bits (enumeration index) + +This bit-packing allows V8 to pass property metadata efficiently and perform quick checks using bitmasks. + +### Generalization vs. Transitions + +It is important to distinguish between **Generalization** (representation changes) and **Transitions** (adding fields): +* **Transition**: Occurs when a new property is added to an object, leading to a new Map. +* **Generalization**: Occurs when the value assigned to an *existing* property requires a broader representation (e.g., storing a double in a field previously marked as `kSmi`). + +If a property is initialized as a `Smi` and later assigned a `Double`, V8 will **generalize** the representation. This may require **Map Deprecation** (marking the old map as invalid for new objects) and creating a new map with the generalized representation. Objects with the old deprecated map are not updated immediately; instead, they are lazily migrated to the new map when they are next accessed or mutated. V8 cannot generalize "backwards" to a more specific representation. + +> [!NOTE] +> A field representation change (generalization) is one of the ways to trigger a **Lazy Deoptimization** in optimized code that relied on the more specific representation. See [Deoptimization](../runtime/deoptimization.md) for details. + +> Some representation changes can be done **in-place** without deprecating the map. Specifically, generalizing from `Smi`, `Double`, or `HeapObject` to `Tagged` can be done in-place. However, changing representation from `Smi` to `Double` requires deprecation because doubles might require a box allocation (e.g., `HeapNumber`). + +### Slack Tracking + +When V8 allocates a new object instance, it often allocates more space than currently needed for properties (in-object slack). +* **Purpose**: To allow adding more properties without needing to resize the object or allocate an out-of-object property array. +* **Mechanism**: V8 tracks the number of properties added to instances of a specific map. After a certain number of allocations (typically 7), V8 determines the "actual" number of properties needed and stops slack tracking. +* **Result**: Future instances are allocated with the exact size needed, and any unused slack in existing instances is filled with a filler object (which can be reclaimed by the GC if it is at the end of the object). + +--- + +## Property Locations: Fields vs. Descriptors + +In addition to representation, V8 tracks *where* a property's value is stored, defined by `PropertyLocation` in `src/objects/property-details.h`: + +* **`kField`**: The value is stored in the object instance itself. + * **In-Object**: Stored directly within the `JSObject` memory layout at a fixed offset. + * **Out-of-Object**: Stored in a separate `PropertyArray` pointed to by the object. +* **`kDescriptor`**: The value is stored in the **Descriptor Array** attached to the `Map`. + * This is an optimization for values that are constant across all instances sharing the map. + * **Data Constants**: If a property is assigned a value that V8 determines is constant, it can store the value directly in the descriptor array, saving space in every instance. + * **Accessor Constants**: Getters and setters (methods or `AccessorPair`s) are typically stored here. All instances share the same accessor function references. + +By combining `PropertyKind` (Data vs. Accessor) and `PropertyLocation` (Field vs. Descriptor), V8 can represent: +* **Data Field**: Standard property stored in the instance. +* **Data Descriptor**: Constant property stored in the map. +* **Accessor Descriptor**: Getter/Setter stored in the map. + +--- + +## Elements Kinds + +For indexed properties (arrays), V8 uses **Elements Kinds** to specialize the backing store (`FixedArray` or `FixedDoubleArray`) and optimize operations like `map`, `reduce`, and `forEach`. + +### Common Elements Kinds +Defined in `src/objects/elements-kind.h`, the most common "fast" kinds are: + +* **`PACKED_SMI_ELEMENTS`**: Array contains only Smis and has no holes. Backed by a `FixedArray`. +* **`HOLEY_SMI_ELEMENTS`**: Contains only Smis but has missing indices (holes). +* **`PACKED_DOUBLE_ELEMENTS`**: Contains only unboxed doubles. Backed by a `FixedDoubleArray`. Highly efficient for numerical work. +* **`HOLEY_DOUBLE_ELEMENTS`**: Contains unboxed doubles but has holes. +* **`PACKED_ELEMENTS`**: Contains arbitrary JS objects (tagged values). Backed by a `FixedArray`. +* **`HOLEY_ELEMENTS`**: Contains arbitrary JS objects and has holes. + +### Other Elements Kinds +For completeness, V8 also defines elements kinds for special cases: +* **Non-extensible, Sealed, and Frozen Elements**: Used when objects are made non-extensible, sealed, or frozen (e.g., `PACKED_FROZEN_ELEMENTS`, `HOLEY_SEALED_ELEMENTS`). +* **Sloppy Arguments Elements**: `FAST_SLOPPY_ARGUMENTS_ELEMENTS` and `SLOW_SLOPPY_ARGUMENTS_ELEMENTS` are used for `arguments` objects in sloppy mode. +* **String Wrapper Elements**: `FAST_STRING_WRAPPER_ELEMENTS` and `SLOW_STRING_WRAPPER_ELEMENTS` are used for string wrapper objects. + +### Dictionary Mode Elements + +When an array becomes very sparse or has a large number of elements, V8 may switch from a flat backing store (`FixedArray` or `FixedDoubleArray`) to a dictionary-based representation (`NumberDictionary`). +* **`DICTIONARY_ELEMENTS`**: Elements are stored in a hash table. This saves memory for sparse arrays but makes access slower. + +### Packed vs. Holey +* **Packed**: Every index from `0` to `length-1` is initialized. Accessing elements is direct and fast. +* **Holey**: Some indices are missing (holes). Accessing a hole requires V8 to perform a costly lookup up the prototype chain to see if a value is defined there. + +### Elements Kind Transitions +Elements kinds only transition from more specific to more general through a **lattice**. Once transitioned, they rarely go back: +* `PACKED_SMI` -> `PACKED_DOUBLE` -> `PACKED_ELEMENTS` +* Any `PACKED` kind can transition to its `HOLEY` counterpart. + +> [!NOTE] +> While conceptually elements kinds form a lattice of generalization, V8's implementation in the transition tree linearizes transitions for fast elements kinds to keep the tree simple and avoid path explosion. The linear sequence used is: +> `PACKED_SMI` -> `HOLEY_SMI` -> `PACKED_DOUBLE` -> `HOLEY_DOUBLE` -> `PACKED_ELEMENTS` -> `HOLEY_ELEMENTS` +> This means V8 may create intermediate transition maps (e.g., creating a `HOLEY_SMI` map when transitioning from `PACKED_SMI` to `PACKED_DOUBLE`) even if they are not strictly needed for the final representation. + +**Examples of Transitions:** +```javascript +const array = [1, 2, 3]; // PACKED_SMI_ELEMENTS +array.push(4.56); // Transitions to PACKED_DOUBLE_ELEMENTS +array.push('x'); // Transitions to PACKED_ELEMENTS +array[9] = 1; // Transitions to HOLEY_ELEMENTS (indices 5-8 are holes) +``` + + +## File Structure +* `src/objects/property-details.h`: `Representation` and `PropertyDetails` definitions. +* `src/objects/elements-kind.h`: `ElementsKind` enum and helper predicates. diff --git a/deps/v8/docs/objects/lookup-iterator.md b/deps/v8/docs/objects/lookup-iterator.md new file mode 100644 index 00000000000000..d469c3ebccac82 --- /dev/null +++ b/deps/v8/docs/objects/lookup-iterator.md @@ -0,0 +1,87 @@ +# LookupIterator Architecture + +This document explains the design and functionality of the `LookupIterator` in V8, which is the central mechanism for resolving property accesses on JavaScript objects. + +## Overview + +The `LookupIterator` (`src/objects/lookup.h`) is a stateful iterator used to implement the ECMAScript specification's property lookup rules. It abstracts away the differences between: +* Named properties vs. indexed elements. +* Fast mode vs. dictionary mode objects. +* In-object vs. out-of-object storage. +* Prototype chain walking. +* Special objects like JSProxies and Interceptors. + +Whenever V8 needs to get, set, or delete a property and cannot do it via a fast Inline Cache (IC) hit, it falls back to the `LookupIterator`. + +## The State Machine + +The iterator operates as a state machine. Calling `Next()` advances the iterator to the next state or the next object in the prototype chain. States include: + +* **`NOT_FOUND`**: The property was not found. This is a terminal state. +* **`STRING_LOOKUP_START_OBJECT`**: Initial state for lookup starting from a primitive string. Avoids wrapper object creation. +* **`TYPED_ARRAY_INDEX_NOT_FOUND`**: Typed arrays return undefined immediately for invalid integer indices without walking the prototype chain. +* **`ACCESS_CHECK`**: The object requires an access check (e.g., cross-origin iframe access) before proceeding. +* **`INTERCEPTOR`**: API-level hooks for optionally handling a lookup in embedder code. +* **`JSPROXY`**: The current holder is a `JSProxy`. The lookup must be forwarded to the proxy's handler. +* **`ACCESSOR`**: The property is an accessor (getter/setter) defined by an `AccessorPair` or `AccessorInfo`. +* **`DATA`**: The property was found as a data property (field or constant) in the current `holder`. +* **`WASM_OBJECT`**: WasmGC objects are opaque in JS and appear to have no properties. +* **`MODULE_NAMESPACE`**: The property is accessed on a deferred module namespace. +* **`TRANSITION`**: Intermediate state during a data property write (not observed during lookup). + +## Configuration + +The iterator can be configured via `LookupIterator::Configuration`, which consists of bit flags and convenience combinations: + +* **`kInterceptor`**: Consult embedder interceptors. +* **`kPrototypeChain`**: Walk the prototype chain. + +Convenience combinations: +* **`OWN_SKIP_INTERCEPTOR`**: Only look at the receiver, skip interceptors. +* **`OWN`**: Only look at the receiver, consult interceptors. (Equivalent to `kInterceptor`). +* **`PROTOTYPE_CHAIN_SKIP_INTERCEPTOR`**: Full chain, skip interceptors. (Equivalent to `kPrototypeChain`). +* **`PROTOTYPE_CHAIN`**: Full chain, consult interceptors. (Equivalent to `kPrototypeChain | kInterceptor`). +* **`DEFAULT`**: Same as `PROTOTYPE_CHAIN`. + +## Deep Dive: The Lookup Process + +The core logic of `LookupIterator` is implemented in `src/objects/lookup.cc`. Let's examine the key phases: + +### 1. Start() +When the iterator is created, it calls `Start()`. +* **Fast Path**: If the lookup start object is a `JSReceiver`, it reads its `Map` and calls `LookupInHolder`. +* **Primitive Wrappers**: If the receiver is a primitive (like a string), V8 avoids creating a wrapper object if possible. For strings, it directly checks for the `"length"` property or valid index lookups within the string's length. If not found, it falls back to the prototype of the primitive (e.g., `String.prototype`). + +### 2. LookupInHolder() +This method checks the current `holder` (the object currently being inspected in the chain) for the property. +* **Fast Objects**: It searches the **Descriptor Array** of the holder's Map using a binary search or linear scan depending on size. +* **Dictionary Objects**: It probes the hash table (Property Dictionary) directly. +* If found, it sets the state to `DATA` or `ACCESSOR` and fills in `PropertyDetails`. + +### 3. Next() and NextInternal() +If the property is not found in the current holder, `Next()` is called to move up the prototype chain. +* **Prototype Walking**: `NextInternal` calls `NextHolder(map)` to get the prototype of the current map. +* **Interceptors**: If a holder has an interceptor, the state becomes `INTERCEPTOR`. V8 may need to invoke embedder callbacks. + * **Masking Interceptors**: Can hide properties on the prototype chain. + * **Non-Masking Interceptors**: Cannot hide properties. If a lookup fails on the chain, V8 may restart the lookup to check non-masking interceptors. + +### 4. Property Modification and Transitions +The `LookupIterator` is not just for reading; it also prepares for writes. +* **`PrepareForDataProperty`**: Called before writing to an existing data property. It handles: + * **Elements Kind Transitions**: If writing a double to a SMI array, it transitions the array to `DOUBLE_ELEMENTS`. + * **Representation Generalization**: If writing a double to a SMI field, it triggers a map transition to generalize the field representation. +* **`PrepareTransitionToDataProperty`**: Called when adding a *new* property. It finds or creates a new Map with the added property and sets the iterator state to `TRANSITION`. + +## Elements vs. Properties + +The `LookupIterator` handles both named properties and indexed elements by templating key methods with a `bool is_element` parameter. +* For elements, it bypasses the descriptor array and goes directly to the `ElementsAccessor` of the object to check the backing store. +* Typed arrays have special handling where out-of-bounds accesses immediately return undefined (via `TYPED_ARRAY_INDEX_NOT_FOUND` state) without walking the prototype chain. + +## ConcurrentLookupIterator + +V8 also provides a `ConcurrentLookupIterator` (`src/objects/lookup.h`) for concurrent accesses from a background thread. Despite the name, it is currently an all-static class and not a stateful iterator. It implements safe lookups for specific cases like own data property lookup on fixed COW arrays, strings, and property cells in global objects, handling concurrency issues defensively. + +## File Structure +* `src/objects/lookup.h`: Main header file defining `LookupIterator` and its states. +* `src/objects/lookup.cc`: Implementation of the lookup logic, state transitions, and property accessors. diff --git a/deps/v8/docs/objects/strings.md b/deps/v8/docs/objects/strings.md new file mode 100644 index 00000000000000..9a81dd433a1c00 --- /dev/null +++ b/deps/v8/docs/objects/strings.md @@ -0,0 +1,91 @@ +# Strings in V8 + +Strings are a fundamental data type in JavaScript, and V8 uses a complex hierarchy of string representations to optimize various operations like concatenation, slicing, and internalization. + +## String Representation Hierarchy + +All strings in V8 inherit from the `String` class (defined in `src/objects/string.h`). V8 uses different concrete classes depending on how the string was created and how it is used. + +### 1. Sequential Strings (`SeqString`) +Captures sequential string values where the characters are stored directly in the object. +* **`SeqOneByteString`**: Characters are stored as 8-bit Latin-1 code units. Used for ASCII-like strings. +* **`SeqTwoByteString`**: Characters are stored as 16-bit UTF-16 code units. Used for strings containing non-Latin-1 characters. + +### 2. Cons Strings (`ConsString`) +Describes string values built by using the addition operator (`+`) on strings. +* Instead of copying characters immediately, a `ConsString` is a pair of pointers to the two constituent strings. +* This creates a binary tree of strings, where the leaves are non-Cons strings. +* **Benefit**: Fast concatenation without copying. +* **Flattening**: When a `ConsString` is read or becomes too deep, V8 may "flatten" it by allocating a sequential string and copying the characters into it. +* **Minimum Size**: Cons strings have a minimum size. Very short concatenations may result in a sequential string instead of a cons string to avoid the overhead of small trees. + +### 3. Sliced Strings (`SlicedString`) +Describes strings that are substrings of another sequential string. +* Instead of copying characters for `substr()` or `slice()`, a `SlicedString` contains a pointer to the parent string, an offset, and a length. +* **Benefit**: Fast slicing without copying. +* **Limitation**: Keeps the parent string alive in memory, even if only a small slice is needed. + +### 4. Thin Strings (`ThinString`) +Describes string objects that are just references to another string object. +* They are used for **in-place internalization** when the original string cannot actually be internalized in-place. +* In these cases, the original string is converted to a `ThinString` pointing at its internalized version (which is allocated as a new object). +* In terms of memory layout, they can be thought of as "one-part cons strings". +* **Benefit**: Avoids updating all handles pointing to the original string when it is internalized. +* **GC Behavior**: The GC *may* (but might not) patch pointers to thin strings to instead point directly to the internalized string, eventually allowing the thin string to be reclaimed. + +### 5. External Strings (`ExternalString`) +Describes string values that are backed by a string resource that lies outside the V8 heap (e.g., in the embedder like Chrome or Node.js). +* V8 must ensure that the resource is not deallocated while the `ExternalString` is live. +* They come in one-byte and two-byte variants, similar to sequential strings. V8 accesses the characters directly from the external resource, avoiding copying the data into the V8 heap. + +## String Transitions and Internalization + +### Internalization +When a string is used as a property key (e.g., `obj["prop"]`), V8 **internalizes** it. This means it ensures there is only one unique instance of that string value in the **String Table** (a hash table). +* If the string is already internalized, it returns the existing instance. +* If not, it adds it to the table. +* If a `SeqString` is internalized, it might be changed to an `InternalizedString` in place if possible. +* If it cannot be changed in place (e.g., if it's a `ConsString`), V8 creates a new `InternalizedString` and converts the original string into a `ThinString` pointing to the new one. + +### Flattening +As mentioned above, `ConsString` instances are tree structures. To read characters efficiently or pass them to APIs that expect flat buffers, V8 will flatten the tree into a single `SeqString`. + +## String Instance Types and Bitfield + +V8 uses the `InstanceType` field in the object Map to identify the specific representation and encoding of a string. For strings, the high-order bits (bits 7-15) are cleared, and the lower bits form a bitfield: + +* **Bits 0-2 (Representation)**: + * `000`: Sequential String + * `001`: Cons String + * `010`: External String + * `011`: Sliced String + * `101`: Thin String +* **Bit 3 (Encoding)**: + * `0`: Two-Byte (UTF-16) + * `1`: One-Byte (Latin-1) +* **Bit 4 (Uncached External)**: Set if the data pointer of an external string is not cached. +* **Bit 5 (Internalization)**: + * `0`: Internalized String + * `1`: Not Internalized String +* **Bit 6 (Shared)**: Set if the string is accessible by more than one thread. + +This bitfield layout allows V8 to perform extremely fast checks (e.g., checking if a string is one-byte or internalized) using simple bitwise operations. + +## The String Table + +The **String Table** is a hash table that stores all internalized strings. + +### How it Works +* **Uniqueness**: Every string value in the table is unique. +* **Lookup**: When V8 needs to internalize a string, it first computes its hash and looks it up in the String Table. +* **Sharing**: If found, the existing string instance is returned. If not found, the new string is added to the table. +* **Use Case**: Property names, symbol descriptions, and common identifiers are internalized to allow fast comparison by pointer equality instead of character-by-character comparison. + +### Thread Safety +* **Shared String Table**: V8 can be configured to use a single shared string table across all isolates in a process (enabled by default when the V8 Sandbox or shared isolates are used). +* **Locking**: Access to the shared string table is protected by locks to ensure thread safety when multiple isolates are internalizing strings concurrently. + +## File Structure +* `src/objects/string.h`: Main header file defining the string hierarchy. +* `src/objects/string.tq`: Torque definitions for strings. +* `src/snapshot/code-serializer.cc`: Handles serialization of strings for code caching. diff --git a/deps/v8/docs/official-support.md b/deps/v8/docs/official-support.md new file mode 100644 index 00000000000000..59f99847e037dd --- /dev/null +++ b/deps/v8/docs/official-support.md @@ -0,0 +1,22 @@ +--- +title: 'Officially supported configurations' +description: 'This document explains which build configurations are maintained by the V8 team.' +--- +V8 supports a multitude of different build configurations across operating systems, their versions, architecture ports, build flags and so on. + +The rule of thumb: If we support it, we have a bot running on one of our [continuous integration consoles](https://ci.chromium.org/p/v8/g/main/console). + +Some nuances: + +- Breakages on the most important builders will block code submission. A tree sheriff will usually revert the culprit. +- Breakages on roughly the same [set of builders](https://chromium.googlesource.com/infra/infra/+/main/infra/services/lkgr_finder/config/v8_cfg.pyl) block our continuous roll into Chromium. +- Some architecture ports are [handled externally](/docs/ports). +- Some configurations are [experimental](https://ci.chromium.org/p/v8/g/experiments/console). Breakages are permitted and will be handled by the owners of the configuration. + +If you have a configuration that exhibits a problem, but is not covered by one of the bots above: + +- Feel free to submit a CL that fixes your problem. The team will support you with a code review. +- You can use v8-dev@googlegroups.com to discuss the problem. +- If you think we should support this configuration (maybe a hole in our test matrix?), please file a bug on the [V8 issue tracker](https://bugs.chromium.org/p/v8/issues/entry) and ask. + +However, we don’t have the bandwidth to support every possible configuration. diff --git a/deps/v8/docs/overview.md b/deps/v8/docs/overview.md new file mode 100644 index 00000000000000..a44afdee3d71e2 --- /dev/null +++ b/deps/v8/docs/overview.md @@ -0,0 +1,53 @@ +# V8 High-Level Overview + +V8 is Google's open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Google Chrome and in Node.js, among others. + +This document provides a high-level overview of V8's architecture and execution pipeline. + +## Execution Pipeline + +V8 executes JavaScript code using a multi-tier execution pipeline. The goal is to start executing code as quickly as possible and then optimize hot code for peak performance. + +1. **Parsing**: The source code is parsed into an Abstract Syntax Tree (AST). +2. **Ignition (Interpreter)**: V8's interpreter, Ignition, generates bytecode from the AST and executes it. This allows for fast startup. +3. **Sparkplug (Baseline Compiler)**: A fast non-optimizing compiler that compiles bytecode to machine code. It runs quickly and provides a decent speedup over interpretation. +4. **Maglev (Mid-tier Compiler)**: An optimizing compiler that sits between Sparkplug and TurboFan. It generates better code than Sparkplug but compiles faster than TurboFan. +5. **TurboFan / Turboshaft (Optimizing Compiler)**: V8's peak optimizing compiler tier. TurboFan is being transitioned to Turboshaft, which uses a new, more efficient linear intermediate representation (IR) based on a control-flow graph (CFG). It generates highly optimized machine code for hot functions. + +## Key Components + +### Parser (`src/parsing/`) +Responsible for scanning and parsing JavaScript source code into an Abstract Syntax Tree (AST). + +### Interpreter (`src/interpreter/`) +Ignition is V8's register-based interpreter. It executes bytecode and collects profiling information used by optimizing compilers. + +### Compilers +- **Sparkplug (`src/baseline/`)**: Compiles bytecode directly to machine code without complex optimizations. +- **Maglev (`src/maglev/`)**: Generates optimized code quickly, filling the gap between Sparkplug and TurboFan. +- **TurboFan (`src/compiler/`)**: V8's traditional peak optimizing compiler based on a sea-of-nodes IR. +- **Turboshaft (`src/compiler/turboshaft/`)**: The new optimizing compiler pipeline that replaces TurboFan's sea-of-nodes IR with a more efficient linear IR. + +### Heap and Garbage Collector (`src/heap/`) +V8 manages memory in a garbage-collected heap. It uses a generational garbage collector with a young generation (semi-space) and an old generation. It also employs concurrent and parallel marking and sweeping techniques to minimize pause times. + +### Objects and Maps (`src/objects/`) +V8 uses "Maps" (also known as hidden classes or shapes) to represent the structure of JavaScript objects. This allows for fast property access via Inline Caching (IC). + +### WebAssembly (`src/wasm/`) +V8 provides a full-featured WebAssembly implementation, including a streaming compiler and integration with the JavaScript garbage collector. + +### Sandbox (`src/sandbox/`) +A security feature that protects the integrity of the V8 heap by ensuring that memory corruptions cannot easily access memory outside the sandbox. + +### Builtins (`src/builtins/`) +Implementations of JavaScript built-in objects and functions, often written in Torque or CodeStubAssembler for performance. + +### Snapshots (`src/snapshot/`) +Used to speed up startup by serializing the heap state and deserializing it when new isolates are created. + +### Public API (`include/` and `src/api/`) +V8 can be embedded in other C++ applications. The public API is defined in `include/` and implemented in `src/api/`. + +## See Also +- [v8.dev/docs](https://v8.dev/docs) for official documentation. diff --git a/deps/v8/docs/parsing/lazy-parsing-and-preparser.md b/deps/v8/docs/parsing/lazy-parsing-and-preparser.md new file mode 100644 index 00000000000000..897852a268a5e4 --- /dev/null +++ b/deps/v8/docs/parsing/lazy-parsing-and-preparser.md @@ -0,0 +1,76 @@ +# Lazy Parsing and the Preparser + +This document explains V8's strategy for fast JavaScript parsing, focusing on lazy parsing and the preparser, as described in the "Blazingly fast parsing" series on v8.dev. + +## The Problem: Too Much Code + +Web pages often ship much more JavaScript than is needed for initial startup. Eagerly parsing and compiling all this code has significant costs: +* **CPU Time**: Wasted on compiling code that might never run. +* **Memory**: Code objects take up heap space. +* **Disk Cache**: Compiled code is cached, taking up disk space. + +To mitigate this, V8 uses **Lazy Parsing**. + +## The Preparser + +When V8 encounters a function during top-level parsing, it often decides to "pre-parse" it instead of fully parsing and compiling it. + +* **Bare Minimum**: The preparser does the bare minimum needed to skip over the function. +* **Syntax Validation**: It verifies that the function is syntactically valid. +* **No AST**: It does *not* build an Abstract Syntax Tree (AST). +* **Scope Info**: It produces the necessary scope and variable information needed for the outer function to be compiled correctly. + +When the function is actually called, it is fully parsed and compiled on-demand. + +## The Variable Allocation Challenge + +The main complexity in pre-parsing is **variable allocation** for closures. + +If an inner function references a variable declared in an outer function, that variable cannot be allocated on the stack (since the outer function's frame will disappear). It must be allocated in a heap-based **Context**. + +To know whether to allocate a variable on the stack or in a context, the preparser must track variable declarations and references across scopes, even though it is skipping the function body. + +### Shadowing and Ambiguity +JavaScript syntax can be ambiguous (e.g., arrow functions vs. destructuring). The preparser must correctly resolve whether a reference actually targets an outer variable or a shadowed inner one. + +## Sharing Code: `ParserBase` and CRTP + +To avoid code duplication and divergence between the full parser and the preparser, V8 uses the **Curiously Recurring Template Pattern (CRTP)**. + +Both `Parser` and `PreParser` inherit from a shared `ParserBase`: + +```cpp +template +class ParserBase { ... }; + +class Parser : public ParserBase { ... }; +class PreParser : public ParserBase { ... }; +``` + +This allows maximum code sharing for the complex logic of variable tracking and spec-compliance checks while allowing specific overrides for AST building vs. skipping. + +## Avoiding Non-Linear Parse Costs + +In early versions of V8, when a lazy function was finally called and needed to be compiled, V8 had to re-preparse its inner functions to figure out scope resolution again. In deeply nested code (common with module bundlers), this led to non-linear parse times. + +To solve this, V8 produces serialized log data during pre-parsing, known as **PreparseData** (handled by `PreparseDataBuilder`). When the outer function is finally compiled, it reads this metadata to know where variables live, without needing to re-preparse the inner functions. + +## Eager Parsing Heuristics + +To avoid pre-parsing functions that are likely to be executed immediately, V8 uses heuristics to detect them and eagerly parses and compiles them. + +### PIFEs: Possibly-Invoked Function Expressions +* **Parentheses**: An open parenthesis before a function expression (e.g., `(function(){...})`) is a strong hint that it will be called immediately. +* **Prefix operators**: The specific prefix operator `!` before a function (e.g., `!function(){...}()`), common in minifiers like UglifyJS, also triggers eager compilation. + +### Compile Hints and Magic Comments +V8 also supports "magic comments" to guide eager vs. lazy compilation (when enabled by flags): +* **`//# allFunctionsCalledOnLoad`**: Hints that all functions in the script should be eagerly compiled. +* **`//# functionsCalledOnLoad=`**: Contains VLQ Base64 encoded data specifying the positions of functions that should be eagerly compiled. + +--- + +## See Also +- `src/parsing/preparser.h`: Implementation of the preparser. +- `src/parsing/parser-base.h`: The shared base class using CRTP. +- [Blazingly fast parsing, part 2: lazy parsing](https://v8.dev/blog/preparser) on v8.dev. diff --git a/deps/v8/docs/parsing/parser-and-ast.md b/deps/v8/docs/parsing/parser-and-ast.md new file mode 100644 index 00000000000000..103ea02edec7df --- /dev/null +++ b/deps/v8/docs/parsing/parser-and-ast.md @@ -0,0 +1,60 @@ +# Parsing and AST in V8 + +Parsing is the process of taking JavaScript source code and turning it into a structured representation that the engine can understand and execute. V8 uses a recursive descent parser to create an Abstract Syntax Tree (AST). + +## The Parsing Pipeline + +The process involves several stages: + +1. **Scanning (Lexical Analysis)**: The `Scanner` reads the raw character stream of the source code and breaks it down into a sequence of **tokens** (e.g., `Token::kIf`, `Token::kIdentifier`, `Token::kSmi`). Tokens are defined in `src/parsing/token.h`. +2. **Parsing (Syntactic Analysis)**: The `Parser` consumes the tokens and builds the **Abstract Syntax Tree (AST)** according to the grammar of JavaScript. + +## The Scanner + +The `Scanner` (defined in `src/parsing/scanner.h`) is responsible for breaking the raw character stream into tokens. It is highly optimized as it is the cornerstone of parser performance. + +Key optimizations and design choices include: +* **UTF-16 Stream**: The scanner operates on a UTF-16 encoded stream of characters to match JavaScript strings and avoid branching for different encodings. +* **Lookahead**: It uses a maximum lookahead of 4 characters to disambiguate tokens. +* **ASCII Lookup Table**: For common identifier characters (a-z, A-Z, 0-9, $, _), it uses a fast lookup table to check `ID_Start` and `ID_Continue` properties without expensive Unicode checks. +* **Perfect Hashing for Keywords**: To quickly identify keywords (like `if`, `else`, `function`), V8 uses a perfect hash function generated by `gperf` based on the length and the first two characters of the identifier. +* **`AdvanceUntil`**: A templatized helper that allows the scanner direct access to the underlying stream data in a tight loop, minimizing function call overhead. +* **Internalization**: All string literals and identifiers are deduplicated (internalized) on the boundary between the scanner and the parser. + +## Eager vs. Lazy Parsing + +To improve startup time and reduce memory usage, V8 does not parse all JavaScript code eagerly. + +* **Eager Parsing**: The full AST is built immediately. This is used for code that is executed right away (like top-level code). +* **Lazy Parsing**: Functions that are not immediately executed are skipped by the full parser and processed by the **Pre-Parser**. + +### The Pre-Parser + +The `PreParser` is a stripped-down version of the parser. + +* It checks for syntax errors. +* It records information about the scope and variable declarations. +* It does **not** build a full AST or generate bytecode. +* When a lazily parsed function is eventually called, it is fully parsed (eagerly) at that time. + +To share implementation details between the full `Parser` and the `PreParser` without virtual function overhead, V8 uses a C++ template base class, `ParserBase` (defined in `src/parsing/parser-base.h`), using the Curiously Recurring Template Pattern (CRTP). Both `Parser` and `PreParser` inherit from `ParserBase` passing themselves as the template argument. + +## The Abstract Syntax Tree (AST) + +The AST is a tree structure where each node represents a construct in the source code. AST nodes are defined in `src/ast/ast.h`. The AST is the final product of the parser and serves as the input for bytecode generation by Ignition (see [Ignition](../interpreter/interpreter-ignition.md)). + +Key Node Types: + +* **`FunctionLiteral`**: Represents a function definition. It is the root of the AST for a function. +* **`Block`**: A sequence of statements. +* **`ExpressionStatement`**: A statement that consists of a single expression. +* **`Literal`**: Represents a constant value (e.g., a number, string, or boolean). +* **`VariableProxy`**: Represents a reference to a variable. It is resolved to a `Variable` in a specific `Scope` during scope analysis. + +## Scope Analysis + +During or immediately after parsing, V8 performs scope analysis to resolve variable references to their declarations. This is where the relationships documented in [Scopes and ScopeInfos](../runtime/scopes-and-scope-infos.md) are established. + +## See Also +- [Scopes and ScopeInfos](../runtime/scopes-and-scope-infos.md) +- [Ignition](../interpreter/interpreter-ignition.md) diff --git a/deps/v8/docs/ports.md b/deps/v8/docs/ports.md new file mode 100644 index 00000000000000..c5d111f94b214d --- /dev/null +++ b/deps/v8/docs/ports.md @@ -0,0 +1,29 @@ +--- +title: 'Handling of ports' +description: 'This document describes how architecture-specific V8 ports should be handled.' +--- +This document describes how ports should be handled. + +## ARM + +For straight-forward ARM ports, do them yourself. If there are difficulties or questions, contact the ARM team in the CL by adding `v8-arm-ports@googlegroups.com` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-arm-ports@googlegroups.com)). + +## MIPS (not officially supported) + +The Mips team will do the port. Contact/CC the MIPS team in the CL if needed by adding `v8-mips-ports@googlegroups.com` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-mips-ports@googlegroups.com)). + +## PPC (not officially supported) + +The PPC team will do the port. Contact/CC the PPC team in the CL if needed by adding `v8-ppc-ports@googlegroups.com` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-ppc-ports@googlegroups.com)). + +## s390 (not officially supported) + +The s390 team will do the port. Contact/CC the s390 team in the CL if needed by adding `v8-s390-ports@googlegroups.com` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-s390-ports@googlegroups.com)). + +## RISC-V (not officially supported) + +The Risc-V team will do the port. Contact/CC the Risc-V team in the CL if needed by adding `v8-risc-v-ports@chromium.org` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-risc-v-ports@chromium.org)). + +## Loong64 (not officially supported) + +The Loong64 team will do the port. Contact/CC the team in the CL if needed by adding `v8-loongarch64-ports@chromium.org` to the reviewer or CC list. For questions you can email the group ([mailto link](mailto:v8-loongarch64-ports@chromium.org)). diff --git a/deps/v8/docs/profile-chromium.md b/deps/v8/docs/profile-chromium.md new file mode 100644 index 00000000000000..f37f91706146a3 --- /dev/null +++ b/deps/v8/docs/profile-chromium.md @@ -0,0 +1,59 @@ +--- +title: 'Profiling Chromium with V8' +description: 'This document explains how to use V8’s CPU and heap profilers with Chromium.' +--- +[V8’s CPU & heap profilers](/docs/profile) are trivial to use from V8’s shells, but it may appear confusing how to use them with Chromium. This page should help you with it. + +## Why is using V8’s profilers with Chromium different from using them with V8 shells? + +Chromium is a complex application, unlike V8 shells. Below is the list of Chromium features that affect profiler usage: + +- each renderer is a separate process (OK, not actually each, but let’s omit this detail), so they can’t share the same log file; +- sandbox built around renderer process prevents it from writing to a disk; +- Developer Tools configure profilers for their own purposes; +- V8’s logging code contains some optimizations to simplify logging state checks. + +## How to run Chromium to get a CPU profile? + +Here is how to run Chromium in order to get a CPU profile from the start of the process: + +```bash +./Chromium --no-sandbox --user-data-dir=`mktemp -d` --incognito --js-flags='--prof' +``` + +Please note that you wouldn’t see profiles in Developer Tools, because all the data is being logged to a file, not to Developer Tools. + +### Flags description + +`--no-sandbox` turns off the renderer sandbox so chrome can write to the log file. + +`--user-data-dir` is used to create a fresh profile, use this to avoid caches and potential side-effects from installed extensions (optional). + +`--incognito` is used to further prevent pollution of your results (optional). + +`--js-flags` contains the flags passed to V8: + +- `--logfile=%t.log` specifies a name pattern for log files. `%t` gets expanded into the current time in milliseconds, so each process gets its own log file. You can use prefixes and suffixes if you want, like this: `prefix-%t-suffix.log`. By default every isolate gets a separate log file. +- `--prof` tells V8 to write statistical profiling information into the log file. + +## Android + +Chrome on Android has a number of unique points that make it a bit more complex to profile. + +- The command line must be written via `adb` before starting Chrome on the device. As a result, quotes in the command line sometimes get lost, and it is best to separate arguments in `--js-flags` with a comma rather than trying to use whitespace and quotes. +- The path for the logfile must be specified as an absolute path to somewhere that is writable on Android’s filesystem. +- The sandboxing used for renderer processes on Android means that even with `--no-sandbox`, the renderer process still can’t write to files on the filesystem, therefore `--single-process` needs to be passed to run the renderer in the same process as the browser process. +- The `.so` is embedded in Chrome’s APK which means symbolization needs to convert from APK memory addresses to the unstripped `.so` file in the builds. + +The following commands enable profiling on Android: + +```bash +./build/android/adb_chrome_public_command_line --no-sandbox --single-process --js-flags='--logfile=/storage/emulated/0/Download/%t.log,--prof' + +adb pull /storage/emulated/0/Download/ +./src/v8/tools/linux-tick-processor --apk-embedded-library=out/Release/lib.unstripped/libchrome.so --preprocess +``` + +## Notes + +Under Windows, be sure to turn on `.MAP` file creation for `chrome.dll`, but not for `chrome.exe`. diff --git a/deps/v8/docs/profile.md b/deps/v8/docs/profile.md new file mode 100644 index 00000000000000..4e662c53fb5bed --- /dev/null +++ b/deps/v8/docs/profile.md @@ -0,0 +1,172 @@ +--- +title: 'Using V8’s sample-based profiler' +description: 'This document explains how to use V8’s sample-based profiler.' +--- +V8 has built-in sample-based profiling. Profiling is turned off by default, but can be enabled via the `--prof` command-line option. The sampler records stacks of both JavaScript and C/C++ code. + +## Build + +Build the `d8` shell following the instructions at [Building with GN](/docs/build-gn). + +## Command line + +To start profiling, use the `--prof` option. When profiling, V8 generates a `v8.log` file which contains profiling data. + +Windows: + +```bash +build\Release\d8 --prof script.js +``` + +Other platforms (replace `ia32` with `x64` if you want to profile the `x64` build): + +```bash +out/ia32.release/d8 --prof script.js +``` + +## Process the generated output + +Log file processing is done using JS scripts running by the d8 shell. For this to work, a `d8` binary (or symlink, or `d8.exe` on Windows) must be in the root of your V8 checkout, or in the path specified by the environment variable `D8_PATH`. Note: this binary is just used to process the log, but not for the actual profiling, so it doesn’t matter which version etc. it is. + +**Make sure `d8` used for analysis was not built with `is_component_build`!** + +Windows: + +```bash +tools\windows-tick-processor.bat v8.log +``` + +Linux: + +```bash +tools/linux-tick-processor v8.log +``` + +macOS: + +```bash +tools/mac-tick-processor v8.log +``` + +## Web UI for `--prof` + +Preprocess the log with `--preprocess` (to resolve C++ symbols, etc). + +```bash +$V8_PATH/tools/linux-tick-processor --preprocess > v8.json +``` + +Open [`tools/profview/index.html`](https://v8.dev/tools/head/profview) in your browser and select the `v8.json` file there. + +## Example output + +``` +Statistical profiling result from benchmarks\v8.log, (4192 ticks, 0 unaccounted, 0 excluded). + + [Shared libraries]: + ticks total nonlib name + 9 0.2% 0.0% C:\WINDOWS\system32\ntdll.dll + 2 0.0% 0.0% C:\WINDOWS\system32\kernel32.dll + + [JavaScript]: + ticks total nonlib name + 741 17.7% 17.7% LazyCompile: am3 crypto.js:108 + 113 2.7% 2.7% LazyCompile: Scheduler.schedule richards.js:188 + 103 2.5% 2.5% LazyCompile: rewrite_nboyer earley-boyer.js:3604 + 103 2.5% 2.5% LazyCompile: TaskControlBlock.run richards.js:324 + 96 2.3% 2.3% Builtin: JSConstructCall + ... + + [C++]: + ticks total nonlib name + 94 2.2% 2.2% v8::internal::ScavengeVisitor::VisitPointers + 33 0.8% 0.8% v8::internal::SweepSpace + 32 0.8% 0.8% v8::internal::Heap::MigrateObject + 30 0.7% 0.7% v8::internal::Heap::AllocateArgumentsObject + ... + + + [GC]: + ticks total nonlib name + 458 10.9% + + [Bottom up (heavy) profile]: + Note: percentage shows a share of a particular caller in the total + amount of its parent calls. + Callers occupying less than 2.0% are not shown. + + ticks parent name + 741 17.7% LazyCompile: am3 crypto.js:108 + 449 60.6% LazyCompile: montReduce crypto.js:583 + 393 87.5% LazyCompile: montSqrTo crypto.js:603 + 212 53.9% LazyCompile: bnpExp crypto.js:621 + 212 100.0% LazyCompile: bnModPowInt crypto.js:634 + 212 100.0% LazyCompile: RSADoPublic crypto.js:1521 + 181 46.1% LazyCompile: bnModPow crypto.js:1098 + 181 100.0% LazyCompile: RSADoPrivate crypto.js:1628 + ... +``` + +## Profiling web applications + +Today’s highly optimized virtual machines can run web apps at blazing speed. But one shouldn’t rely only on them to achieve great performance: a carefully optimized algorithm or a less expensive function can often reach many-fold speed improvements on all browsers. [Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/)’ [CPU Profiler](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference) helps you analyze your code’s bottlenecks. But sometimes, you need to go deeper and more granular: this is where V8’s internal profiler comes in handy. + +Let’s use that profiler to examine the [Mandelbrot explorer demo](https://web.archive.org/web/20130313064141/http://ie.microsoft.com/testdrive/performance/mandelbrotexplorer/) that Microsoft [released](https://blogs.msdn.microsoft.com/ie/2012/11/13/ie10-fast-fluid-perfect-for-touch-and-available-now-for-windows-7/) together with IE10. After the demo release, V8 has fixed a bug that slowed down the computation unnecessarily (hence the poor performance of Chrome in the demo’s blog post) and further optimized the engine, implementing a faster `exp()` approximation than what the standard system libraries provide. Following these changes, **the demo ran 8× faster than previously measured** in Chrome. + +But what if you want the code to run faster on all browsers? You should first **understand what keeps your CPU busy**. Run Chrome (Windows and Linux [Canary](https://tools.google.com/dlpage/chromesxs)) with the following command line switches, which causes it to output profiler tick information (in the `v8.log` file) for the URL you specify, which in our case was a local version of the Mandelbrot demo without web workers: + +```bash +./chrome --js-flags='--prof' --no-sandbox 'http://localhost:8080/' +``` + +When preparing the test case, make sure it begins its work immediately upon load, and close Chrome when the computation is done (hit Alt+F4), so that you only have the ticks you care about in the log file. Also note that web workers aren’t yet profiled correctly with this technique. + +Then, process the `v8.log` file with the `tick-processor` script that ships with V8 (or the new practical web version): + +```bash +v8/tools/linux-tick-processor v8.log +``` + +Here’s an interesting snippet of the processed output that should catch your attention: + +``` +Statistical profiling result from null, (14306 ticks, 0 unaccounted, 0 excluded). + [Shared libraries]: + ticks total nonlib name + 6326 44.2% 0.0% /lib/x86_64-linux-gnu/libm-2.15.so + 3258 22.8% 0.0% /.../chrome/src/out/Release/lib/libv8.so + 1411 9.9% 0.0% /lib/x86_64-linux-gnu/libpthread-2.15.so + 27 0.2% 0.0% /.../chrome/src/out/Release/lib/libwebkit.so +``` + +The top section shows that V8 is spending more time inside an OS-specific system library than in its own code. Let’s look at what’s responsible for it by examining the “bottom up” output section, where you can read indented lines as “was called by” (and lines starting with a `*` mean that the function has been optimized by TurboFan): + +``` +[Bottom up (heavy) profile]: + Note: percentage shows a share of a particular caller in the total + amount of its parent calls. + Callers occupying less than 2.0% are not shown. + + ticks parent name + 6326 44.2% /lib/x86_64-linux-gnu/libm-2.15.so + 6325 100.0% LazyCompile: *exp native math.js:91 + 6314 99.8% LazyCompile: *calculateMandelbrot http://localhost:8080/Demo.js:215 +``` + +More than **44% of the total time is spent executing the `exp()` function inside a system library**! Adding some overhead for calling system libraries, that means about two thirds of the overall time are spent evaluating `Math.exp()`. + +If you look at the JavaScript code, you’ll see that `exp()` is used solely to produce a smooth grayscale palette. There are countless ways to produce a smooth grayscale palette, but let’s suppose you really really like exponential gradients. Here is where algorithmic optimization comes into play. + +You’ll notice that `exp()` is called with an argument in the range `-4 < x < 0`, so we can safely replace it with its [Taylor approximation](https://en.wikipedia.org/wiki/Taylor_series) for that range, which delivers the same smooth gradient with only a multiplication and a couple of divisions: + +``` +exp(x) ≈ 1 / ( 1 - x + x * x / 2) for -4 < x < 0 +``` + +Tweaking the algorithm this way boosts the performance by an extra 30% compared to latest Canary and 5× to the system library based `Math.exp()` on Chrome Canary. + +![](/_img/docs/profile/mandelbrot.png) + +This example shows how V8’s internal profiler can help you go deeper into understanding your code bottlenecks, and that a smarter algorithm can push performance even further. + +To find out more about how benchmark that represent today’s complex and demanding web applications, read [How V8 measures real-world performance](/blog/real-world-performance). diff --git a/deps/v8/docs/rcs.md b/deps/v8/docs/rcs.md new file mode 100644 index 00000000000000..88fd9a2e7cbadb --- /dev/null +++ b/deps/v8/docs/rcs.md @@ -0,0 +1,64 @@ +--- +title: 'Runtime Call Stats' +description: 'This document explains how to use Runtime Call Stats to get detailed V8-internal metrics.' +--- +[The DevTools Performance panel](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/) gives insights into your web app’s runtime performance by visualizing various Chrome-internal metrics. However, certain low-level V8 metrics aren’t currently exposed in DevTools. This article guides you through the most robust way of gathering detailed V8-internal metrics, known as Runtime Call Stats or RCS, through `chrome://tracing`. + +Tracing records the behavior of the entire browser, including other tabs, windows, and extensions, so it works best when done in a clean user profile, with extensions disabled, and with no other browser tabs open: + +```bash +# Start a new Chrome browser session with a clean user profile and extensions disabled +google-chrome --user-data-dir="$(mktemp -d)" --disable-extensions +``` + +Type the URL of the page you want to measure in the first tab, but do not load the page yet. + +![](/_img/rcs/01.png) + +Add a second tab and open `chrome://tracing`. Tip: you can just enter `chrome:tracing`, without the slashes. + +![](/_img/rcs/02.png) + +Click on the “Record” button to prepare recording a trace. First choose “Web developer” and then select “Edit categories”. + +![](/_img/rcs/03.png) + +Select `v8.runtime_stats` from the list. Depending on how detailed your investigation is, you may select other categories as well. + +![](/_img/rcs/04.png) + +Press “Record” and switch back to the first tab and load the page. The fastest way is to use Ctrl/⌘+1 to directly jump to the first tab and then press Enter to accept the entered URL. + +![](/_img/rcs/05.png) + +Wait until your page has completed loading or the buffer is full, then “Stop” the recording. + +![](/_img/rcs/06.png) + +Look for a “Renderer” section that contains the web page title from the recorded tab. The easiest way to do this is by clicking “Processes”, then clicking “None” to uncheck all entries, and then selecting only the renderer you’re interested in. + +![](/_img/rcs/07.png) + +Select the trace events/slices by pressing Shift and dragging. Make sure you cover _all_ the sections, including `CrRendererMain` and any `ThreadPoolForegroundWorker`s. A table with all the selected slices appears at the bottom. + +![](/_img/rcs/08.png) + +Scroll to the top right of the table and click on the link next to “Runtime call stats table”. + +![](/_img/rcs/09.png) + +In the view that appears, scroll to the bottom to see a detailed table of where V8 spends its time. + +![](/_img/rcs/10.png) + +By flipping open a category you can further drill down into the data. + +![](/_img/rcs/11.png) + +## Command-line interface { #cli } + +Run [`d8`](/docs/d8) with `--runtime-call-stats` to get RCS metrics from the command-line: + +```bash +d8 --runtime-call-stats foo.js +``` diff --git a/deps/v8/docs/regexp/architecture.md b/deps/v8/docs/regexp/architecture.md new file mode 100644 index 00000000000000..dd876f5234ac3b --- /dev/null +++ b/deps/v8/docs/regexp/architecture.md @@ -0,0 +1,39 @@ +# RegExp Engine (Irregexp) Architecture + +This document describes the architecture of V8's regular expression engine, **Irregexp**. + +## Overview + +Irregexp is a highly optimized regular expression engine. It does not use a simple backtracking NFA/DFA interpreter by default (though an experimental non-backtracking engine exists). Instead, it compiles regular expressions either directly into **native machine code** or into a specialized **bytecode** that is executed by a dedicated interpreter. + +## The Compilation Pipeline + +Irregexp has its own complete mini-compiler pipeline: + +1. **Parsing**: The `Parser` (`src/regexp/regexp-parser.h`) parses the regular expression pattern string into a specialized Abstract Syntax Tree (AST) defined in `src/regexp/regexp-ast.h`. Note that AST classes are not prefixed with `RegExp` (e.g., `Tree`, `Disjunction`). +2. **Node Graph Generation**: The AST is converted into a graph of `Node` objects (`src/regexp/regexp-nodes.h`). This graph represents the state machine for matching. Similar to AST classes, Node classes are not prefixed with `RegExp` (e.g., `Node`, `TextNode`). +3. **Optimization**: The engine performs analysis on the graph, such as computing `eats_at_least` (minimum characters needed to match) and setting up Boyer-Moore lookahead tables for fast scanning. +4. **Code Generation**: The `Compiler` (`src/regexp/regexp-compiler.h`) traverses the graph and generates code using `RegExpMacroAssembler`. + * **Native Target**: Generates raw machine code for the target architecture. + * **Bytecode Target**: Generates Irregexp bytecode. + +## Execution Modes + +Irregexp can execute in two main modes, defined by `regexp::CompilationTarget`: + +* **`kNative`**: The engine generates machine code. This provides the fastest execution but consumes more memory for the generated code. +* **`kBytecode`**: The engine generates bytecode. This is interpreted by `IrregexpInterpreter` (`src/regexp/regexp-interpreter.h`). This saves memory and is useful on platforms where JIT compilation is not allowed or for less frequently used regexps. + +## Key Optimizations + +* **Boyer-Moore Lookahead**: For non-anchored regular expressions, Irregexp uses a Boyer-Moore-like skip table to quickly skip characters in the subject string that cannot possibly match the start of the pattern. +* **Quick Check**: A mechanism that loads multiple characters at once and uses a mask-and-compare strategy to quickly reject non-matches. +* **Traces**: During code generation, the compiler uses `Trace` objects to track the current state (character position, deferred actions, backtracking stack) to generate efficient code paths and avoid redundant work. + +## File Structure +* `src/regexp/`: Core RegExp implementation. +* `src/regexp/regexp-parser.h` / `.cc`: Parser. +* `src/regexp/regexp-ast.h`: AST definitions. +* `src/regexp/regexp-compiler.h` / `.cc`: Compiler. +* `src/regexp/regexp-interpreter.h` / `.cc`: Bytecode interpreter. +* `src/regexp/regexp-nodes.h`: Graph node definitions. diff --git a/deps/v8/docs/release-process.md b/deps/v8/docs/release-process.md new file mode 100644 index 00000000000000..8640ccc8ec0b84 --- /dev/null +++ b/deps/v8/docs/release-process.md @@ -0,0 +1,68 @@ +--- +title: 'Release process' +description: 'This document explains the V8 release process.' +--- +The V8 release process is tightly connected to [Chrome’s](https://www.chromium.org/getting-involved/dev-channel). The V8 team is using all four Chrome release channels to push new versions to the users. + +If you want to look up what V8 version is in a Chrome release you can check [Chromiumdash](https://chromiumdash.appspot.com/releases). For each Chrome release a separate branch is created in the V8 repository to make the trace-back easier e.g. for [Chrome M121](https://chromium.googlesource.com/v8/v8/+log/refs/branch-heads/12.1). + +## Canary releases + +Every day a new Canary build is pushed to the users via [Chrome’s Canary channel](https://www.google.com/chrome/browser/canary.html?platform=win64). Normally the deliverable is the latest, stable enough version from [main](https://chromium.googlesource.com/v8/v8.git/+/refs/heads/main). + +Branches for a Canary normally look like this: + +## Dev releases + +Every week a new Dev build is pushed to the users via [Chrome’s Dev channel](https://www.google.com/chrome/browser/desktop/index.html?extra=devchannel&platform=win64). Normally the deliverable includes the latest stable enough V8 version on the Canary channel. + + +## Beta releases + +Roughly every 2 weeks a new major branch is created e.g. [for Chrome 94](https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/9.4). This is happening in sync with the creation of [Chrome’s Beta channel](https://www.google.com/chrome/browser/beta.html?platform=win64). The Chrome Beta is pinned to the head of V8’s branch. After approx. 2 weeks the branch is promoted to Stable. + +Changes are only cherry-picked onto the branch in order to stabilize the version. + +Branches for a Beta normally look like this + +``` +refs/branch-heads/12.1 +``` + +They are based on a Canary branch. + +## Stable releases + +Roughly every 4 weeks a new major Stable release is done. No special branch is created as the latest Beta branch is simply promoted to Stable. This version is pushed to the users via [Chrome’s Stable channel](https://www.google.com/chrome/browser/desktop/index.html?platform=win64). + +Branches for a Stable release normally look like this: + +``` +refs/branch-heads/12.1 +``` + +They are promoted (reused) Beta branches. + +## API + +Chromiumdash is also providing an API to collect the same information: + +``` +https://chromiumdash.appspot.com/fetch_milestones (to get the V8 branch name e.g. refs/branch-heads/12.1) +https://chromiumdash.appspot.com/fetch_releases (to get the the V8 branch git hash) +``` + +The following parameter are helpful: +mstone=121 +channel=Stable,Canary,Beta,Dev +platform=Mac,Windows,Lacros,Linux,Android,Webview,etc. + +## Which version should I embed in my application? + +The tip of the same branch that Chrome’s Stable channel uses. + +We often backmerge important bug fixes to a stable branch, so if you care about stability and security and correctness, you should include those updates too — that’s why we recommend “the tip of the branch”, as opposed to an exact version. + +As soon as a new branch is promoted to Stable, we stop maintaining the previous stable branch. This happens every four weeks, so you should be prepared to update at least this often. + +**Related:** [Which V8 version should I use?](/docs/version-numbers#which-v8-version-should-i-use%3F) diff --git a/deps/v8/docs/respectful-code.md b/deps/v8/docs/respectful-code.md new file mode 100644 index 00000000000000..c68bbe0262c91c --- /dev/null +++ b/deps/v8/docs/respectful-code.md @@ -0,0 +1,53 @@ +--- +title: 'Respectful code' +description: 'Inclusivity is central to V8’s culture, and our values include treating each other with dignity. As such, it’s important that everyone can contribute without facing the harmful effects of bias and discrimination.' +--- + +Inclusivity is central to V8’s culture, and our values include treating each other with dignity. As such, it’s important that everyone can contribute without facing the harmful effects of bias and discrimination. However, terms in our codebase, UIs, and documentation can perpetuate that discrimination. This document sets forth guidance which aims to address disrespectful terminology in code and documentation. + +## Policy { #policy } + +Terminology that is derogatory, hurtful, or perpetuates discrimination, either directly or indirectly, should be avoided. + +## What is in scope for this policy? { #scope } + +Anything that a contributor would read while working on V8, including: + +- Names of variables, types, functions, files, build rules, binaries, exported variables, ... +- Test data +- System output and displays +- Documentation (both inside and outside of source files) +- Commit messages + +## Principles { #principles } + +- Be respectful: derogatory language shouldn’t be necessary to describe how things work. +- Respect culturally sensitive language: some words may carry significant historical or political meanings. Please be mindful of this and use alternatives. + +## How do I know if particular terminology is OK or not? { #questions } + +Apply the principles above. If you have any questions, you can reach out to `v8-dev@googlegroups.com`. + +## What are examples of terminology to be avoided? { #examples } + +This list is NOT meant to be comprehensive. It contains a few examples that people have run into frequently. + +:::table-wrapper +| Term | Suggested alternatives | +| --------- | ------------------------------------------------------------- | +| master | primary, controller, leader, host | +| slave | replica, subordinate, secondary, follower, device, peripheral | +| whitelist | allowlist, exception list, inclusion list | +| blacklist | denylist, blocklist, exclusion list | +| insane | unexpected, catastrophic, incoherent | +| sane | expected, appropriate, sensible, valid | +| crazy | unexpected, catastrophic, incoherent | +| redline | priority line, limit, soft limit | +::: + +## What if I am interfacing with something that violates this policy? { #violations } + +This circumstance has come up a few times, particularly for code implementing specifications. In these circumstances, differing from the language in the specification may interfere with the ability to understand the implementation. For these circumstances, we suggest one of the following, in order of decreasing preference: + +1. If using alternate terminology doesn’t interfere with understanding, use alternate terminology. +1. Failing that, do not propagate the terminology beyond the layer of code that is performing the interfacing. Where necessary, use alternative terminology at the API boundaries. diff --git a/deps/v8/docs/runtime/deoptimization.md b/deps/v8/docs/runtime/deoptimization.md new file mode 100644 index 00000000000000..cc7a3e430b61b6 --- /dev/null +++ b/deps/v8/docs/runtime/deoptimization.md @@ -0,0 +1,123 @@ +# Deoptimization in V8 + +Deoptimization (often called "deopt") is the process of moving execution from optimized code (generated by TurboFan or Maglev) back to unoptimized code (Ignition interpreter). This is necessary because optimized code makes optimistic assumptions about types and shapes of objects that may be violated at runtime. + +V8 has three types of deoptimization (defined by `DeoptimizeKind` in `src/common/globals.h`): **Eager**, **Lazy**, and **LazyAfterFastCall** (a specialized variant of lazy deoptimization used for direct calls to C++). + +## Eager Deoptimization + +Eager deoptimization occurs immediately when a check in the optimized code fails. + +### How it works: +1. **Speculative Optimization**: When TurboFan/Maglev generates code, it inserts checks (guards) based on feedback collected by Ignition. For example, it assumes a variable is always a Smi. +2. **Check Failure**: If execution reaches a point where the assumption is violated (e.g., a Smi becomes a HeapNumber), the guard fails. +3. **Immediate Exit**: The code executes a jump to a dedicated deoptimization exit point. These exits are small stubs generated at the end of the optimized function. +4. **State Reconstruction**: The deoptimizer takes over, reads the current register and stack state, and reconstructs the equivalent interpreter frame(s). + +Eager deopts are synchronous and happen at the exact instruction that failed the check. + +## Lazy Deoptimization + +Lazy deoptimization occurs when an assumption made by optimized code is invalidated by an external event, rather than a check failure within the code itself. + +### How it works: +1. **Invalidation**: An event occurs that invalidates optimized code. Examples include: + * A prototype chain changes. + * A function is redefined. + * A map transition changes. +2. **Marking**: V8 marks the dependent optimized code as invalid (using `code->set_marked_for_deoptimization`). +3. **Execution Continues**: The optimized code may still be running on the stack. It is not immediately interrupted. +4. **Return Trigger**: The next time execution returns to the marked optimized frame (or calls another function from it that triggers a stack check), V8 detects that the code is invalid. +5. **Deferred Exit**: V8 patches the return address to point to a lazy deoptimization builtin, which then enters the deoptimizer. + +Lazy deopts are asynchronous relative to the code execution and are checked at specific safepoints or return sites. + +## Frame Translation (Recreating the Frame) + +The most complex part of deoptimization is reconstructing the interpreter frame(s) from the optimized frame state. This is handled by `TranslatedState` (defined in `src/deoptimizer/translated-state.h`). + +### The Problem +Optimized code may have: +- Inlined functions (one optimized frame represents multiple source frames). +- Eliminated operations (dead code elimination). +- Variables stored in registers instead of the stack. +- Objects allocated only in registers (Escape Analysis). + +### The Solution: Translation Data +During compilation, TurboFan/Maglev generates **Deoptimization Data** (specifically a `DeoptimizationFrameTranslation`). This is a compact bytecode stream that describes how to reconstruct the unoptimized state for every point where a deopt can occur. + +### Translation Opcodes +The translation data uses opcodes (defined in `src/deoptimizer/translation-opcode.h`) to instruct the deoptimizer on how to fill the slots of the reconstructed interpreter frame: +- **LITERAL**: Use a constant from the literal pool. +- **TAGGED_STACK_SLOT**, **INT32_STACK_SLOT**, **DOUBLE_STACK_SLOT**, etc.: Read a value of a specific type from a slot in the optimized frame. +- **REGISTER**, **INT32_REGISTER**, **DOUBLE_REGISTER**, etc.: Read a value of a specific type from a CPU register. +- **DUPLICATED_OBJECT**: Reference an object that has already been materialized. +- **CAPTURED_OBJECT**: Reconstruct an object that was optimized away by escape analysis. + +### Reconstruction Process +1. **Read Translation**: The deoptimizer reads the translation data for the current PC (Program Counter). +2. **Build `TranslatedState`**: It creates a `TranslatedState` object containing a list of `TranslatedFrame`s. Each `TranslatedFrame` corresponds to one interpreter frame (including inlined ones). +3. **Materialize Objects**: If the translation references captured objects, the deoptimizer allocates them on the heap and fills their fields. +4. **Fill Stack Frames**: The deoptimizer allocates a new set of stack frames for the interpreter and fills them with the values resolved from registers, stack slots, and literals. +5. **Set Accumulator**: The interpreter's accumulator is set to the result of the last operation (if applicable). +6. **Resume Ignition**: Execution is transferred to the Ignition interpreter at the appropriate bytecode offset. + +### Visualizing Frame Translation + +```dot +digraph G { + rankdir=TB; + newrank=true; + node [shape=record]; + edge []; + + subgraph cluster_opt { + label="Optimized Stack"; + OF [label="Optimized Frame"]; + } + + subgraph cluster_table { + label="Translation Table"; + TT [label="Deopt Data"]; + } + + subgraph cluster_recon { + label="Reconstructed Stack"; + Stack [shape=record, label="{ Interpreter Frame 1\n(Inlined Function) | Interpreter Frame 2\n(Outer Function) }"]; + } + + Deopt [label="Deoptimizer"]; + Heap [label="Heap", shape=cylinder]; + Ignition [label="Ignition Interpreter"]; + + OF -> Deopt [label="1. Trigger Deopt"]; + TT -> Deopt [label="2. Lookup PC"]; + Deopt -> Heap [label="3. Materialize Objects"]; + Deopt -> Stack [label="4. Construct Frames"]; + Stack -> Ignition [label="5. Resume"]; +} +``` + +## Builtin Continuations + +When deoptimization occurs while execution is inside a builtin function (e.g., a builtin written in CodeStubAssembler or Torque), V8 cannot simply resume at a bytecode offset in the interpreter, because the builtin execution was not driven by bytecode. + +To handle this, V8 uses **Builtin Continuations**. + +### How they work: +1. **Special Frames**: During frame translation, the deoptimizer may create special continuation frames (e.g., `BUILTIN_CONTINUATION_FRAME`, `JAVASCRIPT_BUILTIN_CONTINUATION_FRAME`). +2. **State Setup**: These frames are set up with a specific return address pointing to a continuation builtin (e.g., `ContinueToCodeStubBuiltin` or `ContinueToJavaScriptBuiltin`). +3. **Resuming**: When execution resumes, these continuation builtins are executed. They are responsible for taking the result of the operation (or the exception) and either returning it to the caller or continuing execution in the interpreter at the appropriate place. + +### Completing Inlined Builtins +Continuation builtins can do more than just return; they can **complete the execution of an inlined builtin** before resuming the bytecode. +* **Example**: If `Array.prototype.forEach` is inlined by TurboFan and a deopt occurs inside the callback, V8 cannot just jump back to the interpreter's `Call` bytecode (which invoked `forEach`) because we might be in the middle of the loop. +* **Solution**: V8 generates specialized continuation builtins like `ArrayForEachLoopLazyDeoptContinuation` (defined in `src/builtins/array-foreach.tq`). This continuation knows how to resume the loop from the current index (`initialK`) and complete the remaining iterations before finally returning to the interpreter. + +Continuations ensure that even if we deoptimize in the middle of a complex native operation, we don't lose the result and can safely transition back to interpreted JavaScript. + +--- + +## See Also +- [Ignition](../interpreter/interpreter-ignition.md) +- [TurboFan](../compiler/turbofan/compiler-turbofan.md) diff --git a/deps/v8/docs/runtime/exception-handling.md b/deps/v8/docs/runtime/exception-handling.md new file mode 100644 index 00000000000000..3f75f216321f55 --- /dev/null +++ b/deps/v8/docs/runtime/exception-handling.md @@ -0,0 +1,89 @@ +# Exception Handling in V8 + +Exception handling in V8 is implemented using side-tables rather than explicit bytecodes for entering and leaving `try` blocks. This ensures zero overhead for the "happy path" (when no exception is thrown). + +## The Handler Table + +The core data structure for exception handling is the `HandlerTable` (defined in `src/codegen/handler-table.h`). It maps code regions or specific instructions to their corresponding exception handlers. + +There are two flavors of handler tables, depending on the execution tier: + +### 1. Range-Based Handler Table (Unoptimized Code) + +Used by **Ignition** (interpreter) and **Sparkplug** (baseline compiler). It is stored as a `TrustedByteArray` attached to the `BytecodeArray`. + +Since unoptimized code is relatively linear and compact, it is efficient to use ranges to describe `try` blocks. + +**Layout:** +An array of 4-element entries: +`[ range-start , range-end , handler-offset , handler-data ]` + +* **range-start**: The bytecode offset where the `try` block begins. +* **range-end**: The bytecode offset where the `try` block ends. +* **handler-offset**: The bytecode offset of the `catch` or `finally` block. It also encodes prediction information (whether it's likely to catch the exception) and a flag indicating if the handler was used. +* **handler-data**: The index of the context register. + +**Zero-Overhead Try Blocks:** +When generating bytecode for a `try-catch` statement, the `BytecodeGenerator` does not emit any bytecodes to "enter" the try block. Instead, it calls `MarkTryBegin` and `MarkTryEnd` on the `BytecodeArrayBuilder`, which records the offsets in the `HandlerTableBuilder`. The execution proceeds linearly. + +### 2. Return-Address-Based Handler Table (Optimized Code) + +Used by **Maglev** and **TurboFan**. It is stored directly in the instruction stream of the generated code. + +Optimized code can be heavily reordered and scheduled, making ranges impractical. Instead, V8 tracks specific instructions that can throw (primarily calls) and maps their return addresses to handlers. + +**Layout:** +An array of 2-element entries: +`[ return-address-offset , handler-offset ]` + +* **return-address-offset**: The offset from the start of the code where a call returns. If the call throws, the return address is used to look up the handler. +* **handler-offset**: The offset in the generated code where the handler starts. + +## Exception Flow across Tiers + +### Ignition +1. **Try Entry**: No operation. +2. **Throw**: The `Throw` or `ReThrow` bytecode is executed, or a C++ runtime function throws an exception. +3. **Lookup**: The runtime looks up the current bytecode offset in the `BytecodeArray`'s `HandlerTable` using `LookupHandlerIndexForRange`. +4. **Unwinding**: If found, the interpreter restores the context (saved in a register at `try` entry) and jumps to the handler offset. If not found, it unwinds the stack frame and continues searching in the caller. + +### Sparkplug +Sparkplug shares the `BytecodeArray` with Ignition and therefore reuses the same range-based `HandlerTable`. When an exception occurs in Sparkplug code, it can often be handled directly in Sparkplug or it might deoptimize to Ignition to handle it. + +### Maglev & TurboFan +1. **Try Entry**: No operation. +2. **Throw**: An instruction (like a call) throws an exception. +3. **Lookup**: The runtime uses the return address of the throwing call to look up the handler in the code object's return-address-based `HandlerTable` using `LookupReturn`. +4. **Unwinding**: The runtime unwinds the stack to the handler and resumes execution there. + +## Lazy Deoptimization on Throw + +In optimized code (Maglev and TurboFan), V8 sometimes uses a mechanism called **Lazy Deopt on Throw** for certain calls. + +Instead of generating complex exception handling code (catch blocks) in the optimized code itself, V8 can mark a call descriptor with `LazyDeoptOnThrow::kYes`. + +**How it works:** +1. **Sentinel Handler**: In the return-address-based handler table, instead of mapping to a real handler offset, the entry for that call maps to a special sentinel value (`kLazyDeoptOnThrowSentinel` which is -1). +2. **Exception Trigger**: If the called function throws an exception, the runtime exception search looks up the handler. +3. **Deopt Trigger**: When it finds the sentinel value, it knows that it should not branch to a catch block in the optimized code. Instead, it triggers a **Lazy Deoptimization** of the frame. +4. **Interpreter Handles It**: The frame is translated back to an Ignition interpreter frame, and the exception is handled by Ignition's standard range-based handler table lookup. + +This simplifies optimized code generation for operations where exceptions are rare or where generating optimized catch blocks would be too costly. + +## Catch Prediction +V8 uses "Catch Prediction" to guess whether an exception will be caught locally. This is used by the debugger to pause on uncaught exceptions. +* `CAUGHT`: The exception is caught by a local `catch` block. +* `UNCAUGHT`: The exception will (likely) rethrow the exception to outside the code boundary. +* `PROMISE`: The exception will be caught and cause a promise rejection. +* `ASYNC_AWAIT`: The exception will be caught and cause a promise rejection in the desugaring of an async function. +* `UNCAUGHT_ASYNC_AWAIT`: The exception will be caught and cause a promise rejection in the desugaring of an async REPL script. + +> [!NOTE] +> We cannot perform exception prediction on optimized code directly. Instead, V8 uses `FrameSummary` to find the corresponding code offset in unoptimized code to perform prediction there. + +--- + +## See Also +- [Stack Walking](stack-walking.md) +- [Ignition](../interpreter/interpreter-ignition.md) +- [Function Architecture](function-architecture.md) diff --git a/deps/v8/docs/runtime/function-architecture.md b/deps/v8/docs/runtime/function-architecture.md new file mode 100644 index 00000000000000..99a2e5181f9373 --- /dev/null +++ b/deps/v8/docs/runtime/function-architecture.md @@ -0,0 +1,240 @@ +# Function Architecture in V8 + +To execute JavaScript functions efficiently, V8 splits function data into **context-independent** and **context-dependent** parts. This separation allows sharing of heavy assets (like bytecode) while allowing specific instances (closures) to maintain their own state and feedback. + +This document describes this architecture and how functions are chained together both statically and dynamically. + +## Context-Independent Data: `SharedFunctionInfo` + +Data that does not change regardless of where or how many times a function is instantiated is stored in the `SharedFunctionInfo` (SFI). + +* **Purpose**: To save memory by sharing read-only information across all instances of the function, even across different `NativeContext`s. +* **Key Contents**: + * **Bytecode**: The executable bytecode generated by Ignition. + * **`ScopeInfo`**: The lexical structure of the scope (see [Scopes and ScopeInfos](scopes-and-scope-infos.md)). + * **Source Positions**: Mapping bytecode to source code lines. + * **`FeedbackMetadata`**: Describes the shape and size of the `FeedbackVector` that needs to be allocated for this function. + +### SFI Chaining via Bytecode +`SharedFunctionInfo` objects do not form a direct linked list. Instead, they form a tree structure embedded within the bytecode. +When a function contains a nested function definition, the outer function's `BytecodeArray` is responsible for creating the closure for the inner function. +1. **Inner SFI in Constant Pool**: The SFI for the inner function is created during parsing/compilation of the outer function and is placed in the **Constant Pool** of the outer function's `BytecodeArray`. +2. **`CreateClosure` Bytecode**: The outer function's bytecode contains a `CreateClosure` instruction at the point where the inner function is defined/created. +3. **Reference**: The `CreateClosure` bytecode takes an operand that is the index of the inner SFI in the constant pool. + +## Context-Dependent Data + +Data that depends on the specific execution context or function instance is stored in objects linked from the `JSFunction`. + +### `JSFunction` +A `JSFunction` represents an actual JavaScript function object available to the user code (a closure). +* **Purpose**: To represent a specific instance of a function with its own scope chain and execution state. +* **Key Contents**: + * **Link to `SharedFunctionInfo`**: Points to the shared data. + * **`Context`**: Points to the execution context (lexical environment) where the function was created. This is what makes it a closure. + * **`FeedbackCell`**: Points to a cell that holds the `FeedbackVector`. + * **`JSDispatchHandle`**: In modern V8, this is a 32-bit index into the `JSDispatchTable`, used to find the executable code, enabling efficient tiering. + +### `FeedbackCell` +The `FeedbackCell` acts as a level of indirection between the `JSFunction` and the `FeedbackVector`. +* **Purpose**: + * **Tiering Control**: It stores the `interrupt_budget`, which is decremented on function entry and backward branches. When it reaches zero, it triggers a tiering request. + * **Lazy Allocation**: It allows V8 to delay the allocation of the full `FeedbackVector` until the function becomes "hot". + * **Sharing**: In some cases, multiple closures can share the same `FeedbackCell` if they are guaranteed to have the same feedback behavior. + +### `FeedbackVector` +The `FeedbackVector` holds the runtime feedback (Inline Caches) used by the optimizing compilers. +* **Purpose**: To collect data about the types and shapes of objects the function operates on. +* **Key Contents**: + * **Slots**: Array of slots, each corresponding to an operation in the bytecode. + * **`ClosureFeedbackCellArray`**: Holds `FeedbackCell`s for inner closures. +* **Context Dependency**: Feedback is highly dependent on the types encountered in a specific context. Sharing feedback across different contexts with different types would lead to polymorphism and deoptimizations. + +## FeedbackVector Chaining via `CreateClosure` Slots + +The dynamic chaining happens through the feedback system, specifically to allow inner functions to have their own feedback vectors when they become hot. + +1. **`ClosureFeedbackCellArray`**: Every `FeedbackVector` (and also uncompiled `FeedbackCell`s that are preparing for vector allocation) contains a `ClosureFeedbackCellArray`. +2. **Slot per Closure**: For every `CreateClosure` bytecode in a function, there is a corresponding slot in its `ClosureFeedbackCellArray`. +3. **Pre-allocated FeedbackCells**: This array is populated with `FeedbackCell`s *before* the closures are actually created. +4. **Passing the Cell**: When `CreateClosure` is executed, it looks up the pre-allocated `FeedbackCell` from the outer function's `ClosureFeedbackCellArray` and links it to the new `JSFunction`. + +This creates a runtime chain: +`Outer JSFunction` -> `Outer FeedbackVector` -> `ClosureFeedbackCellArray` -> `Inner FeedbackCell` -> `Inner FeedbackVector` (once allocated). + +## Modern V8 Features + +### Sharing of `JSDispatchHandle` +1. **Initialization**: Each `FeedbackCell` in `ClosureFeedbackCellArray` is allocated a `JSDispatchHandle` (initially pointing to `CompileLazy`). +2. **Closure Creation**: `CreateClosure` copies the `JSDispatchHandle` from the `FeedbackCell` into the new `JSFunction`. +3. **Shared Dispatch**: Closures created from the same site share the same `JSDispatchTable` entry. +4. **Efficient Tiering**: Updating the code pointer in the table entry updates all sharing closures immediately. + +### `FeedbackCell` State Transitions +V8 tracks the number of closures created from a site using the `Map` of the `FeedbackCell`: +* `NoClosuresCellMap` -> `OneClosureCellMap` -> `ManyClosuresCellMap` +These help decide when to allocate a `FeedbackVector` and manage specialized code. + +## Concrete Example + +Consider the following code: + +```javascript +// Top-level script +function outer() { + function inner() { + return 42; + } + return inner; +} + +outer(); // Call to outer +``` + +### Object Graph + +Here is what the object graph looks like after the top-level script has been executed and `outer()` has been called, but before `inner()` is called. + +```dot +digraph G { + rankdir=TB; + newrank=true; + node [shape=record]; + edge []; + + subgraph cluster_static { + label="Static Structure (SFIs)"; + TL_SFI [label="Top-level Script (SFI)"]; + Outer_SFI [label="outer (SFI)"]; + Inner_SFI [label="inner (SFI)"]; + + TL_SFI -> Outer_SFI [label="via Bytecode's\nConstant Pool"]; + Outer_SFI -> Inner_SFI [label="via Bytecode's\nConstant Pool"]; + } + + subgraph cluster_dynamic { + label="Dynamic Instances (Runtime)"; + TL_JSF [label="Top-level Script (JSFunction)"]; + TL_FC [label="FeedbackCell"]; + CC_TL [label="CompileScript"]; + TL_FV [label="FeedbackVector"]; + Outer_FC [label="FeedbackCell\n(for outer)"]; + CC_Outer [label="CreateClosure\n(Outer)"]; + Outer_JSF [label="outer (JSFunction)"]; + Outer_FV [label="FeedbackVector"]; + Inner_FC [label="FeedbackCell\n(for inner)"]; + CC_Inner [label="CreateClosure\n(Inner)"]; + Inner_JSF [label="inner (JSFunction)"]; + Inner_FV [label="FeedbackVector\nor Undefined"]; + + TL_FC -> TL_JSF [style=invis]; + TL_FC -> CC_TL [label="consumed by", style=dashed]; + CC_TL -> TL_JSF [label="creates", style=dashed]; + + TL_JSF -> TL_FC; + TL_FC -> TL_FV; + TL_FV -> Outer_FC [label="contains"]; + + Outer_FC -> Outer_JSF [style=invis]; + Outer_FC -> CC_Outer [label="consumed by", style=dashed]; + CC_Outer -> Outer_JSF [label="creates", style=dashed]; + + Outer_JSF -> Outer_FC; + Outer_FC -> Outer_FV; + Outer_FV -> Inner_FC [label="contains"]; + + Inner_FC -> Inner_JSF [style=invis]; + Inner_FC -> CC_Inner [label="consumed by", style=dashed]; + CC_Inner -> Inner_JSF [label="creates", style=dashed]; + + Inner_JSF -> Inner_FC; + Inner_FC -> Inner_FV; + } + + TL_SFI -> CC_TL [label="consumed by", style=dashed]; + Outer_SFI -> CC_Outer [label="consumed by", style=dashed]; + Inner_SFI -> CC_Inner [label="consumed by", style=dashed]; + + TL_JSF -> TL_SFI; + Outer_JSF -> Outer_SFI; + Inner_JSF -> Inner_SFI; + + TL_JSF -> Outer_JSF [style=invis]; + Outer_JSF -> Inner_JSF [style=invis]; + + { rank="same"; TL_SFI; TL_FC; } + { rank="same"; Outer_SFI; Outer_FC; } + { rank="same"; Inner_SFI; Inner_FC; } +} +``` + +### Scope and Context Graph + +This graph shows how `ScopeInfo` (static) and `Context` (dynamic) are linked. + +```dot +digraph G { + rankdir=TB; + newrank=true; + node [shape=record]; + edge []; + + subgraph cluster_static { + label="Static Structure (Scopes)"; + TL_SFI [label="Top-level Script (SFI)"]; + TL_SI [label="Top-level ScopeInfo"]; + Outer_SFI [label="outer (SFI)"]; + Outer_SI [label="outer ScopeInfo"]; + Inner_SFI [label="inner (SFI)"]; + Inner_SI [label="inner ScopeInfo"]; + + TL_SFI -> TL_SI; + Outer_SFI -> Outer_SI [constraint=false]; + Inner_SFI -> Inner_SI [constraint=false]; + + Inner_SI -> Outer_SI -> TL_SI [label="parent"]; + } + + subgraph cluster_dynamic { + label="Dynamic Instances (Contexts)"; + TL_JSF [label="Top-level Script (JSFunction)"]; + TL_Ctx [label="Top-level Context"]; + Outer_JSF [label="outer (JSFunction)"]; + Outer_Ctx [label="outer Context"]; + Inner_JSF [label="inner (JSFunction)"]; + Inner_Ctx [label="inner Context"]; + + TL_JSF -> TL_Ctx; + Outer_JSF -> Outer_Ctx [constraint=false]; + Inner_JSF -> Inner_Ctx [constraint=false]; + + Inner_Ctx -> Outer_Ctx -> TL_Ctx [label="parent"]; + } + + TL_Ctx -> TL_SI [constraint=false]; + Outer_Ctx -> Outer_SI [constraint=false]; + Inner_Ctx -> Inner_SI [constraint=false]; + + TL_JSF -> TL_SFI [constraint=false]; + Outer_JSF -> Outer_SFI [constraint=false]; + Inner_JSF -> Inner_SFI [constraint=false]; + + TL_SFI -> Outer_SFI -> Inner_SFI [style=invis]; + TL_JSF -> Outer_JSF -> Inner_JSF [style=invis]; + TL_SI -> Outer_SI -> Inner_SI [style=invis]; + TL_Ctx -> Outer_Ctx -> Inner_Ctx [style=invis]; +} +``` + +## Developer Guide: Tracing JSFunction Initialization + +### Key Entry Points +* `JSFunction::CreateAndAttachFeedbackVector` +* `JSFunction::EnsureClosureFeedbackCellArray` +* `FastNewClosure` (Builtin) + +--- + +## See Also +- [Hidden Classes and Inline Caches](hidden-classes-and-ics.md) +- [Scopes and ScopeInfos](scopes-and-scope-infos.md) diff --git a/deps/v8/docs/runtime/hidden-classes-and-ics.md b/deps/v8/docs/runtime/hidden-classes-and-ics.md new file mode 100644 index 00000000000000..1c5a59069d231d --- /dev/null +++ b/deps/v8/docs/runtime/hidden-classes-and-ics.md @@ -0,0 +1,128 @@ +# Hidden Classes and Inline Caches in V8 + +V8 uses a combination of **Hidden Classes (Maps)** and **Inline Caches (ICs)** to achieve high performance in property access and method calls, despite JavaScript being a dynamic language. + +## Hidden Classes (Maps) + +As detailed in [Objects and Maps](../heap/objects-and-maps.md), V8 attaches a `Map` (hidden class) to every JavaScript object. The Map defines the shape of the object, mapping property names to their offsets in memory. + +When objects share the same structure (same properties added in the same order), they share the same Map. This sharing is key to the effectiveness of Inline Caches. + +### Map Transition Tree + +Adding properties to an object transitions it to a new Map. V8 builds a transition tree to reuse Maps when objects follow the same transition path. Note that the order of property addition matters: + +```dot +digraph G { + rankdir=TB; + newrank=true; + node [shape=record]; + edge []; + + Empty [label="Map 0: {}", class="start"]; + MapA [label="Map 1: {a: @0}", class="branch"]; + MapAB [label="Map 2: {a: @0, b: @1}", class="leaf"]; + MapB [label="Map 3: {b: @0}", class="branch"]; + MapBA [label="Map 4: {b: @0, a: @1}", class="leaf"]; + + Empty -> MapA [label="+a"]; + MapA -> MapAB [label="+b"]; + + Empty -> MapB [label="+b"]; + MapB -> MapBA [label="+a"]; +} +``` + +## Inline Caches (ICs) + +Inline Caching is a technique for optimizing dynamic property lookups. Without ICs, V8 would have to perform a dictionary lookup or search the descriptor array of the map every time a property is accessed (e.g., `obj.x`). + +### How ICs Work + +An IC caches the result of a property lookup at the specific location in the code (the call site) where the access occurs. + +1. **Uninitialized State**: When a line of code like `return obj.x` is executed for the first time, the IC at that site is `UNINITIALIZED`. +2. **First Access (Miss)**: V8 performs a slow lookup. It checks the object's Map, finds property `x` in the `DescriptorArray`, and gets its offset. +3. **Caching**: V8 records the object's current Map and the calculated handler (e.g., the field offset or a getter function) in the **Feedback Vector** associated with the current function. The IC transitions to the `MONOMORPHIC` state. +4. **Subsequent Accesses (Hit)**: The next time this code is executed: + * V8 compares the object's current Map with the Map stored in the IC. + * If they match (a Hit), V8 uses the cached handler directly to access the property. This is extremely fast. + * If they don't match (a Miss), V8 falls back to a slower lookup and updates the IC. + +### IC States + +An IC call site can be in one of several states (defined in `src/common/globals.h` as `InlineCacheState`): + +* **`NO_FEEDBACK`**: Used when no feedback should be collected (e.g., in certain debugger scenarios or for always-slow operations). +* **`UNINITIALIZED`**: The call site has never been executed. +* **`MONOMORPHIC`**: The IC has seen only one receiver Map. This is the most optimized state. +* **`RECOMPUTE_HANDLER`**: Check failed due to prototype (or map deprecation). +* **`POLYMORPHIC`**: The IC has seen a small number of different receiver Maps (typically up to 4). It stores a list of Map-handler pairs and checks them linearly. +* **`MEGADOM`**: Many DOM receiver types have been seen for the same accessor. +* **`HOMOMORPHIC`**: Many receiver types have been seen with the same handler. +* **`MEGAMORPHIC`**: The IC has seen many different receiver Maps. It falls back to a global stub cache or a slower, generic lookup path to avoid excessive memory use in the feedback vector. +* **`GENERIC`**: A generic handler is installed and no extra typefeedback is recorded. + +## The Feedback Vector and Slots + +As mentioned above, IC state is stored in the `FeedbackVector`. + +### Structure +* A `FeedbackVector` is associated with a `JSFunction` (instance). +* The `SharedFunctionInfo` (shared across instances) contains `FeedbackMetadata` which describes the layout of the vector. +* It contains an array of slots (`raw_feedback_slots`), defined in `src/objects/feedback-vector.tq`. +* Each IC site in the bytecode has a corresponding slot index in this vector. + +### FeedbackNexus +To avoid manual bit-twiddling and handle the complexity of different slot kinds, V8 uses `FeedbackNexus` (defined in `src/objects/feedback-vector.h`). This is a helper class that knows how to read and write feedback for a specific slot. + +## Handler Encoding + +A common misconception is that Inline Caches always cache a pointer to a generated machine code stub. In modern V8, this is often not the case to save memory. Instead, V8 uses **Handlers** which can be encoded in different ways: + +### 1. Smi Handlers +For simple field accesses, the handler is often just a tagged integer (Smi). The encoding depends on the `Kind` of access. For a simple field load (`kField`), the bits of the Smi encode: +* **Kind**: Encoded in the lowest bits (e.g., `kField`). +* **IsWasmStruct**: Distinguishes JS objects from Wasm structs. +* **Storage Offset**: The offset of the field in words. +* **In-object vs. Out-of-object**: Whether the property is stored directly in the object or in the properties backing store (`IsInobjectBits`). +* **IsDouble**: Whether the field stores a double value. +* **Descriptor Index**: The index in the descriptor array. + +The `AccessorAssembler` (CSA) decodes these Smis directly in assembly to perform the access. + +### 2. DataHandler Objects +For more complex scenarios, such as accessing a property on a prototype object, V8 uses a `DataHandler` heap object (defined in `src/objects/data-handler.tq` and `src/objects/data-handler.h`). This object extends `Struct` and has a variable size to store optional data fields. It contains: +* `smi_handler`: A Smi encoding the handler (like above) or a `Code` object. +* `validity_cell`: A Smi or a `Cell` to check if the prototype chain is still valid. +* `data1`, `data2`, `data3`: Optional data fields (flexible array member in C++) depending on the handler kind. + +For prototype loads, `LoadHandler::LoadFromPrototype` creates a `LoadHandler` (which extends `DataHandler`) and typically stores: +* The **holder** object in the `data1` field (as a weak reference). +* The final access handler in `smi_handler`. + +For interceptors, `LoadHandler::LoadInterceptorHolderIsLookupStartupObject` stores the `InterceptorInfo` in the `data2` field. + +## The Fast Path: AccessorAssembler + +The code that actually executes when an IC site is hit is generated by `AccessorAssembler` (defined in `src/ic/accessor-assembler.cc`). This class uses CodeStubAssembler (CSA) to generate highly optimized machine code for: +* `LoadIC`, `StoreIC`, `KeyedLoadIC`, `KeyedStoreIC`. +* Probing the `FeedbackVector`. +* Handling monomorphic and polymorphic cases. +* Falling back to the runtime on a miss. + +## Megamorphic Stub Cache + +When an IC site sees too many different Maps (becomes megamorphic), storing all of them in the `FeedbackVector` would consume too much memory. + +Instead, V8 falls back to a global **Stub Cache** (defined in `src/ic/stub-cache.h`). +* It is a fixed-size hash table. +* It is keyed by the receiver's **Map** and the property **Name**. +* It stores the handler directly. + +If the `AccessorAssembler` misses in the `FeedbackVector` for a megamorphic site, it probes this global stub cache. This provides a fast path even for highly polymorphic call sites, without bloating the local feedback vector. + +## See Also +- [Objects and Maps](../heap/objects-and-maps.md) +- [Descriptor and Transition Arrays](../objects/descriptor-and-transition-arrays.md) +- [Maps (Hidden Classes) Tutorial](hidden-classes-tutorial.md) diff --git a/deps/v8/docs/runtime/hidden-classes-tutorial.md b/deps/v8/docs/runtime/hidden-classes-tutorial.md new file mode 100644 index 00000000000000..9efcb61de1c570 --- /dev/null +++ b/deps/v8/docs/runtime/hidden-classes-tutorial.md @@ -0,0 +1,236 @@ +--- +title: 'Maps (Hidden Classes) in V8' +description: 'How does V8 track and optimize the perceived structure of your objects?' +--- + +Let's show how V8 builds it's hidden classes. The principal data structures are: + +- `Map`: the hidden class itself. It's the first pointer value in an object and therefore allows easy comparison to see if two objects have the same class. +- `DescriptorArray`: The full list of properties that this class has along with information about them. In some cases, the property value is even in this array. +- `TransitionArray`: An array of "edges" from this `Map` to sibling Maps. Each edge is a property name, and should be thought of as "if I were to add a property with this name to the current class, what class would I transition to?" + +Because many `Map` objects only have one transition to another one (ie, they are "transitional" maps, only used on the way to something else), V8 doesn't always create a full-blown `TransitionArray` for it. Instead it'll just link directly to this "next" `Map`. The system has to do a bit of spelunking in the `DescriptorArray` of the `Map` being pointed to in order to figure out the name attached to the transition. + +This is an extremely rich subject. It's also subject to change, though, if you understand the concepts in this article future change should be incrementally understandable. + +## Why have hidden classes? + +V8 could do without hidden classes, sure. It would treat each object as a bag of properties. However, a very useful principle would have been left laying around: the principal of intelligent design. V8 surmises that you'll only create so many **different** kinds of objects. And each kind of object will be used in what can eventually be seen to be stereotypical ways. I say "eventually be seen" because the JavaScript language is a scripting language, not a pre-compiled one. So V8 never knows what will come next. To make use of intelligent design (that is, the assumption that there is a mind behind the code coming in), V8 has to watch and wait, letting the sense of structure seep in. The hidden class mechanism is the principal means to do this. Of course, it presupposes a sophisticated listening mechanism, and these are the Inline Caches (ICs) about which much has been written. + +So, if you are convinced this is good and necessary work, follow me! + +## An example + +```javascript +function Peak(name, height, extra) { + this.name = name; + this.height = height; + if (isNaN(extra)) { + this.experience = extra; + } else { + this.prominence = extra; + } +} + +m1 = new Peak("Matterhorn", 4478, 1040); +m2 = new Peak("Wendelstein", 1838, "good"); +``` + +With this code we've already got an interesting map tree from the root map (also known as the initial map) which is attached to the function `Peak`: + +
+ Hidden class example +
+ +Each blue box is a map, starting with the initial map. This is the map of the object returned if somehow, we managed to run the function `Peak` without adding a single property. The follow-on maps are the ones that result by adding the properties given by the names on the edges between maps. Each map has a list of the properties associated with an object of that map. Furthermore, it describes the exact location of each property. Finally, from one of these maps, say, `Map3` which is the hidden class of the object you'll get if you passed a number for the `extra` argument in `Peak()`, you can follow a back link up all the way to the initial map. + +Let's draw it again with this extra information. The annotation (i0), (i1), means in-object field location 0, 1, etc: + +
+ Hidden class example +
+ +Now, if you spend time examining these maps before you've created at least 7 `Peak` objects, you'll encounter **slack tracking** which can be confusing. I have [another article](https://v8.dev/blog/slack-tracking) about that. Just create 7 more objects and it will be finished. At this point, your Peak objects will have exactly 3 in-object properties, with no possibility to add more directly in the object. Any additional properties will be offloaded to the object's property backing store. It's just an array of property values, whose index comes from the map (Well, technically, from the `DescriptorArray` attached to the map). Let's add a property to `m2` on a new line, and look again at the map tree: + +```javascript +m2.cost = "one arm, one leg"; +``` + +
+ Hidden class example +
+ +I snuck something in here. Notice that all of the properties are annotated with "const," which means that from V8's point of view, nobody ever changed them since the constructor, so they can be considered constants once they've been initialized. TurboFan (the optimizing compiler) loves this. Say `m2` is referenced as a constant global by a function. Then the lookup of `m2.cost` can be done at compile time, since the field is marked as constant. I'll return to this later in the article. + +Notice that property "cost" is marked as `const p0`, which means it's a constant property stored at index zero in the **properties backing store** rather than in the object directly. This is because we have no more room in the object. This information is visible in `%DebugPrint(m2)`: + +``` +d8> %DebugPrint(m2); +DebugPrint: 0x2f9488e9: [JS_OBJECT_TYPE] + - map: 0x219473fd [FastProperties] + - prototype: 0x2f94876d + - elements: 0x419421a1 [HOLEY_ELEMENTS] + - properties: 0x2f94aecd { + 0x419446f9: [String] in ReadOnlySpace: #name: 0x237125e1 + (const data field 0) + 0x23712581: [String] in OldSpace: #height: + 1838 (const data field 1) + 0x23712865: [String] in OldSpace: #experience: 0x237125f9 + (const data field 2) + 0x23714515: [String] in OldSpace: #cost: 0x23714525 + + (const data field 3) properties[0] + } + ... +{name: "Wendelstein", height: 1, experience: "good", cost: "one arm, one leg"} +d8> +``` + +You can see that we have 4 properties, all marked as const. The first 3 in the object, and the last in `properties[0]` which means the first slot of the properties backing store. We can look at that: + +``` +d8> %DebugPrintPtr(0x2f94aecd) +DebugPrint: 0x2f94aecd: [PropertyArray] + - map: 0x41942be9 + - length: 3 + - hash: 0 + 0: 0x23714525 + 1-2: 0x41942329 +``` + +The extra properties are there just in case you decide to add more all of a sudden. + +## The real structure + +There are different things we could do at this point, but since you must really like V8, having read this far, I'd like to try drawing the real data structures we use, the ones mentioned at the beginning of `Map`, `DescriptorArray`, and `TransitionArray`. Now that you have some idea of the hidden class concept being built up behind the scenes, you may as well bind your thinking more closely to the code through the right names and structures. Let me try and reproduce that last figure in V8's representation. First I'm going to draw the **DescriptorArrays**, which hold the list of properties for a given Map. These arrays can be shared -- the key to that is that the Map itself knows how many properties it is allowed to look at in the DescriptorArray. Since the properties are in the order they were added in time, these arrays can be shared by several maps. See: + +
+ Hidden class example +
+ +Notice that **Map1**, **Map2**, and **Map3** all point to **DescriptorArray1**. The number next to the "descriptors" field in each Map indicates how many fields over in the DescriptorArray belong to the Map. So **Map1**, which only knows about the "name" property, looks only at the first property listed in **DescriptorArray1**. Whereas **Map2** has two properties, "name" and "height." So it looks at the first and second items in **DescriptorArray1** (name and height). This kind of sharing saves a lot of space. + +Naturally, we can't share where there is a split. There is a transition from Map2 over to Map4 if the "experience" property is added, and over to Map3 if the "prominence" property is added. You can see Map4 and Map5 sharing DescriptorArray2 in the same way that DescriptorArray1 was shared among three Maps. + +The only thing missing from our "true to life" diagram is the `TransitionArray` which is still metaphorical at this point. Let's change that. I took the liberty of removing the **back pointer** lines, which cleans things up a bit. Just remember that from any Map in the tree, you can walk up the tree, too. + +
+ Hidden class example +
+ +The diagram rewards study. **Question: what would happen if a new property "rating" was added after "name" instead of going on to "height" and other properties?** + +**Answer**: Map1 would get a real **TransitionArray** so as to keep track of the bifurcation. If property *height* is added, we should transition to **Map2**. However, if property *rating* is added, we should go to a new map, **Map6**. This map would need a new DescriptorArray that mentions *name* and *rating*. The object has extra free slots at this point in the object (only one of three is used), so property *rating* will be given one of those slots. + +*I checked my answer with the help of `%DebugPrintPtr()`, and drew the following:* + +
+ Hidden class example +
+ +No need to beg me to stop, I see that this is the upper limit of such diagrams! But I think you can get a sense of how the parts move. Just imagine if after adding this ersatz property *rating*, we continued on with *height*, *experience* and *cost*. Well, we'd have to create maps **Map7**, **Map8** and **Map9**. Because we insisted on adding this property in the middle of an established chain of maps, we will duplicate much structure. I don't have the heart to make that drawing -- though if you send it to me I will add it to this document :). + +I used the handy [DreamPuf](https://dreampuf.github.io/GraphvizOnline) project to make the diagrams easily. Here is a [link](https://dreampuf.github.io/GraphvizOnline/#digraph%20G%20%7B%0A%0A%20%20node%20%5Bfontname%3DHelvetica%2C%20shape%3D%22record%22%2C%20fontcolor%3D%22white%22%2C%20style%3Dfilled%2C%20color%3D%22%233F53FF%22%5D%0A%20%20edge%20%5Bfontname%3DHelvetica%5D%0A%20%20%0A%20%20Map0%20%5Blabel%3D%22%7B%3Ch%3E%20Map0%20%7C%20%3Cd%3E%20descriptors%20(0)%20%7C%20%3Ct%3E%20transitions%20(1)%7D%22%5D%3B%0A%20%20Map1%20%5Blabel%3D%22%7B%3Ch%3E%20Map1%20%7C%20%3Cd%3E%20descriptors%20(1)%20%7C%20%3Ct%3E%20transitions%20(1)%7D%22%5D%3B%0A%20%20Map2%20%5Blabel%3D%22%7B%3Ch%3E%20Map2%20%7C%20%3Cd%3E%20descriptors%20(2)%20%7C%20%3Ct%3E%20transitions%20(2)%7D%22%5D%3B%0A%20%20Map3%20%5Blabel%3D%22%7B%3Ch%3E%20Map3%20%7C%20%3Cd%3E%20descriptors%20(3)%20%7C%20%3Ct%3E%20transitions%20(0)%7D%22%5D%0A%20%20Map4%20%5Blabel%3D%22%7B%3Ch%3E%20Map4%20%7C%20%3Cd%3E%20descriptors%20(3)%20%7C%20%3Ct%3E%20transitions%20(1)%7D%22%5D%0A%20%20Map5%20%5Blabel%3D%22%7B%3Ch%3E%20Map5%20%7C%20%3Cd%3E%20descriptors%20(4)%20%7C%20%3Ct%3E%20transitions%20(0)%7D%22%5D%0A%20%20Map6%20%5Blabel%3D%22%7B%3Ch%3E%20Map6%20%7C%20%3Cd%3E%20descriptors%20(2)%20%7C%20%3Ct%3E%20transitions%20(0)%7D%22%5D%3B%0A%20%20Map0%3At%20-%3E%20Map1%20%5Blabel%3D%22name%20(inferred)%22%5D%3B%0A%20%20%0A%20%20Map4%3At%20-%3E%20Map5%20%5Blabel%3D%22cost%20(inferred)%22%5D%3B%0A%20%20%0A%20%20%2F%2F%20Create%20the%20descriptor%20arrays%0A%20%20node%20%5Bfontname%3DHelvetica%2C%20shape%3D%22record%22%2C%20fontcolor%3D%22black%22%2C%20style%3Dfilled%2C%20color%3D%22%23FFB34D%22%5D%3B%0A%20%20%0A%20%20DA0%20%5Blabel%3D%22%7BDescriptorArray0%20%7C%20(empty)%7D%22%5D%0A%20%20Map0%3Ad%20-%3E%20DA0%3B%0A%20%20DA1%20%5Blabel%3D%22%7BDescriptorArray1%20%7C%20name%20(const%20i0)%20%7C%20height%20(const%20i1)%20%7C%20prominence%20(const%20i2)%7D%22%5D%3B%0A%20%20Map1%3Ad%20-%3E%20DA1%3B%0A%20%20Map2%3Ad%20-%3E%20DA1%3B%0A%20%20Map3%3Ad%20-%3E%20DA1%3B%0A%20%20%0A%20%20DA2%20%5Blabel%3D%22%7BDescriptorArray2%20%7C%20name%20(const%20i0)%20%7C%20height%20(const%20i1)%20%7C%20experience%20(const%20i2)%20%7C%20cost%20(const%20p0)%7D%22%5D%3B%0A%20%20Map4%3Ad%20-%3E%20DA2%3B%0A%20%20Map5%3Ad%20-%3E%20DA2%3B%0A%20%20%0A%20%20DA3%20%5Blabel%3D%22%7BDescriptorArray3%20%7C%20name%20(const%20i0)%20%7C%20rating%20(const%20i1)%7D%22%5D%3B%0A%20%20Map6%3Ad%20-%3E%20DA3%3B%0A%20%20%0A%20%20%2F%2F%20Create%20the%20transition%20arrays%0A%20%20node%20%5Bfontname%3DHelvetica%2C%20shape%3D%22record%22%2C%20fontcolor%3D%22white%22%2C%20style%3Dfilled%2C%20color%3D%22%23B3813E%22%5D%3B%0A%20%20TA0%20%5Blabel%3D%22%7BTransitionArray0%20%7C%20%3Ca%3E%20experience%20%7C%20%3Cb%3E%20prominence%7D%22%5D%3B%0A%20%20Map2%3At%20-%3E%20TA0%3B%0A%20%20TA0%3Aa%20-%3E%20Map4%3Ah%3B%0A%20%20TA0%3Ab%20-%3E%20Map3%3Ah%3B%0A%20%20%0A%20%20TA1%20%5Blabel%3D%22%7BTransitionArray1%20%7C%20%3Ca%3E%20rating%20%7C%20%3Cb%3E%20height%7D%22%5D%3B%0A%20%20Map1%3At%20-%3E%20TA1%3B%0A%20%20TA1%3Ab%20-%3E%20Map2%3B%0A%20%20TA1%3Aa%20-%3E%20Map6%3B%0A%7D) to the previous diagram. + +## TurboFan and const properties + +Thus far, all these fields are marked in the `DescriptorArray` as `const`. Let's play with this. Run the following code on a debug build: + +```javascript +// run as: +// d8 --allow-natives-syntax --no-lazy-feedback-allocation --code-comments --print-opt-code +function Peak(name, height) { + this.name = name; + this.height = height; +} + +let m1 = new Peak("Matterhorn", 4478); +m2 = new Peak("Wendelstein", 1838); + +// Make sure slack tracking finishes. +for (let i = 0; i < 7; i++) new Peak("blah", i); + +m2.cost = "one arm, one leg"; +function foo(a) { + return m2.cost; +} + +foo(3); +foo(3); +%OptimizeFunctionOnNextCall(foo); +foo(3); +``` + +You'll get a printout of optimized function `foo()`. The code is very short. You'll see at the end of the function: + +``` +... +40 mov eax,0x2a812499 ;; object: 0x2a812499 +45 mov esp,ebp +47 pop ebp +48 ret 0x8 ;; return "one arm, one leg"! +``` + +TurboFan, being a cheeky devil, just directly inserted the value of `m2.cost`. Well how do you like that! + +Of course, after that last call to `foo()` you could insert this line: + +```javascript +m2.cost = "priceless"; +``` + +What do you think will happen? One thing for sure, we can't let `foo()` stay as it is. It would return the wrong answer. Re-run the program, but add flag `--trace-deopt` so you'll be told when optimized code is removed from the system. After the printout of the optimized `foo()`, you'll see these lines: + +``` +[marking dependent code 0x5c684901 0x21e525b9 (opt #0) for deoptimization, + reason: field-const] +[deoptimize marked code in all contexts] +``` + +Wow. + +
+ I like it a lot +
+ +If you force re-optimization you'll get code that is not quite as good, but still benefits greatly from the Map structure we've been describing. Remember from our diagrams that property *cost* is the first property in +the properties backing store for an object. Well, it may have lost it's const designation, but we still have it's address. Basically, in an object with map **Map5**, which we'll certainly verify that global variable `m2` still has, we only have to-- + +1. load the properties backing store, and +2. read out the first array element. + +Let's see that. Add this code below the last line: + +```javascript +// Force reoptimization of foo(). +foo(3); +%OptimizeFunctionOnNextCall(foo); +foo(3); +``` + +Now have a look at the code produced: + +``` +... +40 mov ecx,0x42cc8901 ;; object: 0x42cc8901 +45 mov ecx,[ecx+0x3] ;; Load the properties backing store +48 mov eax,[ecx+0x7] ;; Get the first element. +4b mov esp,ebp +4d pop ebp +4e ret 0x8 ;; return it in register eax! +``` + +Why heck. That's exactly what we said should happen. Perhaps we are beginning to Know. + +TurboFan is also smart enough to deoptimize if variable `m2` ever changes to a different class. You can watch the latest optimized code deoptimize again with something droll like: + +```javascript +m2 = 42; // heh. +``` + +## Where to go from here + +Many options. Map migration. Dictionary mode (aka "slow mode"). Lots to explore in this area and I hope you enjoy yourself as much as I do -- thanks for reading! + +## See Also +- [Hidden Classes and Inline Caches](hidden-classes-and-ics.md) diff --git a/deps/v8/docs/runtime/scopes-and-scope-infos.md b/deps/v8/docs/runtime/scopes-and-scope-infos.md new file mode 100644 index 00000000000000..bd0ef33df750c8 --- /dev/null +++ b/deps/v8/docs/runtime/scopes-and-scope-infos.md @@ -0,0 +1,95 @@ +# Scopes and ScopeInfos in V8 + +V8 manages variable scopes at both compile time and runtime using different data structures. This document explains how `Scope` and `ScopeInfo` work together. + +## Compile-Time: `Scope` + +During parsing and AST generation, V8 uses the `Scope` class (defined in `src/ast/scopes.h`) to represent lexical scopes. + +### Purpose +* **Variable Tracking**: It tracks all variables declared in a scope. +* **Variable Resolution**: It resolves variable references to their declarations. +* **Allocation Decision**: It determines whether a variable can live on the stack (fast) or must be allocated in a `Context` on the heap (slow, needed for closures). + +### Scope Types +V8 supports various scope types defined in `src/common/globals.h`: +* `SCRIPT_SCOPE`: The top-level scope for a script or a top-level eval. +* `REPL_MODE_SCOPE`: The top-level scope for a repl-mode script. +* `CLASS_SCOPE`: The scope introduced by a class. +* `EVAL_SCOPE`: The top-level scope for an eval source. +* `FUNCTION_SCOPE`: The top-level scope for a function. +* `MODULE_SCOPE`: The scope introduced by a module literal. +* `CATCH_SCOPE`: The scope introduced by catch. +* `BLOCK_SCOPE`: The scope introduced by a new block. +* `WITH_SCOPE`: The scope introduced by with. +* `SHADOW_REALM_SCOPE`: Synthetic scope for ShadowRealm NativeContexts. + +## Runtime: `ScopeInfo` + +When V8 compiles a function, it serializes the compile-time `Scope` information into a `ScopeInfo` object (defined in `src/objects/scope-info.h`). + +### Purpose +`ScopeInfo` is a compressed heap object that retains the necessary information about a scope for execution and debugging. + +* **Context Layout**: It tells V8 how many context slots are needed and what variables go into which slots. +* **Debugger Support**: It allows the debugger to inspect variables and understand the scope structure of running code. +* **Deoptimization**: Used to reconstruct stack frames during deoptimization. + +### Contents of ScopeInfo +* **Flags**: Scope type, language mode, receiver info, etc. +* **Counts**: Number of parameters, context-allocated locals. +* **Inlined Local Names**: Names of variables, allowing lookups by name (primarily for debugging and `eval`). +* **Outer Scope Info**: A link to the `ScopeInfo` of the enclosing scope, forming a chain. + +## Runtime: `Context` + +While `ScopeInfo` is read-only metadata, the `Context` is the actual runtime object (a variable-sized heap object, conceptually similar to a `FixedArray`) that holds the values of context-allocated variables. + +* Each `ScopeInfo` that requires a context will have a corresponding `Context` object created at runtime when the scope is entered. +* Contexts are linked in a chain (via the `previous` pointer), mirroring the `ScopeInfo` chain. + +### Context Types +Similar to scope types, V8 has different context types (see `src/objects/contexts.h`): +* **Native Context**: The top-level context for a specific realm. Contains many fixed slots for builtins and global objects. +* **Function Context**: Created for function executions that have context-allocated variables. +* **Block Context**: Created for block scopes with block-scoped declarations (`let`, `const`). +* **Catch Context**: Created for `catch` blocks to hold the exception object. +* **With Context**: Created for `with` statements. +* **Eval Context**: Created for `eval` executions. +* **Module Context**: Created for ES modules. + + +## Example: Context Allocation (Closures) + +To understand how `ScopeInfo` and `Context` work in practice, consider a closure that captures a variable: + +```javascript +function makeCounter() { + let count = 0; + return function() { + return ++count; + }; +} +const counter = makeCounter(); +counter(); // Returns 1 +counter(); // Returns 2 +``` + +### What V8 does: +1. **Compile-Time**: The parser sees that the inner anonymous function references `count`, which is declared in the outer `makeCounter` function. The compiler decides that `count` cannot be stack-allocated and must be **context-allocated**. +2. **ScopeInfo**: The `ScopeInfo` for `makeCounter` will record that it needs a context with at least one slot for `count`. +3. **Runtime Execution**: + * When `makeCounter()` is called, V8 creates a new `FunctionContext` for it. + * The `count` variable is stored in a slot in this context, initialized to `0`. + * The inner function is created as a `JSFunction` object. This object contains a reference to the current `Context` (the `makeCounter` context). + * When `makeCounter` returns, its stack frame is destroyed, but the `FunctionContext` lives on in the heap because the inner function holds a reference to it. + * When `counter()` is called, V8 sets the current context to the one referenced by the closure. The `++count` operation reads and writes directly to the slot in that heap context. + +## Summary + +1. **Parser** creates `Scope` objects. +2. **Compiler** uses `Scope` to allocate variables and generates `ScopeInfo`. +3. **Runtime** uses `ScopeInfo` to create `Context` objects and access variables. + +## See Also +- [Objects and Maps](../heap/objects-and-maps.md) diff --git a/deps/v8/docs/runtime/stack-walking.md b/deps/v8/docs/runtime/stack-walking.md new file mode 100644 index 00000000000000..49666596c1d9f5 --- /dev/null +++ b/deps/v8/docs/runtime/stack-walking.md @@ -0,0 +1,84 @@ +# Stack Walking in V8 + +Stack walking is the process of traversing the call stack to inspect active frames. V8 uses stack walking for several critical features: +* **Exception Handling**: Finding the appropriate catch handler when an exception is thrown. +* **Stack Traces**: Generating the string representation of the stack for `Error.stack`. +* **Garbage Collection**: Identifying root pointers held in stack slots. +* **Profiling**: The CPU profiler samples the stack to determine where time is spent. + +## Frame Types + +V8 has a rich set of frame types, as execution can transition between interpreted JavaScript, optimized JavaScript, WebAssembly, and C++ host code. + +Key frame types (defined in `src/execution/frames.h`): +* **`ENTRY`**: The entry point from C++ into JavaScript. +* **`EXIT`**: The exit point from JavaScript back into C++ (e.g., calling a C++ runtime function). +* **`INTERPRETED`**: A frame for code running in the Ignition interpreter. +* **`BASELINE`**: A frame for code compiled by Sparkplug. +* **`MAGLEV`**: A frame for code compiled by Maglev. +* **`TURBOFAN`**: A frame for code compiled by TurboFan. +* **`BUILTIN`**: A frame for a builtin function (e.g., written in Torque or CSA). +* **`WASM`**: Frames for WebAssembly execution. + +## The Stack Frame Iterator + +The primary mechanism for stack walking in C++ is the `StackFrameIterator` class (and its variants like `DebuggableStackFrameIterator`). + +```cpp +for (StackFrameIterator it(isolate); !it.done(); it.Advance()) { + StackFrame* frame = it.frame(); + // Inspect frame... +} +``` + +### How it Works: +1. **Starting Point**: The iterator typically starts from the current top of the stack (retrieved from the isolate's saved state or current CPU registers). +2. **Frame Identification**: V8 identifies the type of frame by looking at the **Frame Marker** (a special value stored in the frame) or by looking up the PC (Program Counter) in the instruction stream of active code objects. +3. **Navigation**: The iterator uses the saved Frame Pointer (FP) to find the caller's frame. Standard V8 frames maintain a consistent link chain of FPs. + +## Standard Frame Layout + +Most V8 frames follow a standard layout (though optimized frames may vary to save space): + +```text + +---------------------------+ + | Caller's Frame Pointer | <- Higher addresses + +---------------------------+ + | Caller's Return Address | + +---------------------------+ + | Context / Marker | + +---------------------------+ + | Function / Code Object | <- Current FP points here + +---------------------------+ + | ... Locals / Stack ... | <- SP points to the top + +---------------------------+ +``` + +## GC Stack Scanning + +During Garbage Collection, V8 must scan the stack to find all root pointers to heap objects. This process relies on the stack walking infrastructure. + +### Precise vs. Conservative Scanning +V8 primarily uses **Precise Stack Scanning**. It knows exactly which slots on the stack contain tagged pointers and which contain raw data (like integers or floats). +* **Tagged Pointers**: V8 uses pointer tagging (typically the lowest bit being 1 for HeapObjects and 0 for Smis). The GC uses this tag to identify pointers that need to be traced and updated if the object moves. +* **Safepoint Tables**: For optimized code (Maglev and TurboFan), V8 generates **Safepoint Tables**. At specific instruction offsets (safepoints, usually calls), these tables describe exactly which stack slots and registers contain tagged pointers. The GC uses the return address to look up the safepoint table entry. +* **Unoptimized Code**: For Ignition frames, the GC knows that the slots correspond to bytecode registers, which are all treated as tagged values containing either Smis or HeapObjects. + +### Handling Arguments +Arguments to functions can be passed on the stack or in registers, depending on the calling convention and execution tier. +* **JS Linkage**: For standard JavaScript function calls, arguments are pushed onto the stack by the caller. +* **Accessing Arguments**: `CommonFrameWithJSLinkage` provides methods like `GetParameter(index)` to access arguments. The location is calculated relative to the frame pointer. +* **GC Scanning of Arguments**: The GC needs to scan arguments passed on the stack. To do this precisely, V8 frames track the actual number of arguments passed (e.g., via `GetActualArgumentCount()`). This ensures that even with variadic arguments or parameter mismatch, the GC scans exactly the valid range of arguments on the stack. + +## Safe Stack Walking + +Stack walking must be done safely, especially when handling signals for the CPU profiler or during GC when the stack might be in an inconsistent state. + +* **Profiler Safety**: The CPU profiler interrupts execution at arbitrary points. The stack may be in an inconsistent state (e.g., in the middle of pushing a frame). V8 uses a specialized, safe stack walker (`SafeStackFrameIterator`) that performs sanity checks on pointers before dereferencing them to avoid crashes. + +--- + +## See Also +- [Exception Handling](exception-handling.md) +- [Deoptimization](deoptimization.md) +- [Ignition](../interpreter/interpreter-ignition.md) diff --git a/deps/v8/docs/runtime/tiering.md b/deps/v8/docs/runtime/tiering.md new file mode 100644 index 00000000000000..98fcb9af9ae45d --- /dev/null +++ b/deps/v8/docs/runtime/tiering.md @@ -0,0 +1,107 @@ +# Tiering and the Interrupt Budget + +This document explains how V8 manages the transition of functions between different execution tiers (Interpretation, Baseline, Mid-Tier, and Top-Tier optimization) and the mechanism used to trigger these transitions. + +## Execution Tiers + +V8 uses a multi-tiered execution strategy to balance startup time and peak performance: + +1. **Ignition (Interpreter)**: Executes bytecode. Fast startup, low memory overhead, but slower execution. Collects type feedback. +2. **Sparkplug (Baseline Compiler)**: Compiles bytecode directly to machine code without optimizations. Very fast compilation, better performance than Ignition. +3. **Maglev (Mid-Tier Compiler)**: Graph-based optimizing compiler. Fast compilation, generates high-quality code by utilizing type feedback. +4. **TurboFan / Turboshaft (Top-Tier Compiler)**: Advanced optimizing compilers. Slow compilation, but generates the most highly optimized code for peak performance. + +## The Interrupt Budget + +To decide when to promote (or "tier up") a function to a higher tier, V8 uses an **Interrupt Budget** mechanism. + +* Each function has a budget associated with it, stored in its `FeedbackCell` (specifically `interrupt_budget_`). +* The budget is initialized to a certain value (dependent on the current tier and flags). +* As the function executes, the budget is decremented. +* When the budget reaches zero or goes negative, V8 triggers a check to see if the function should be tiered up. + +## Decrementing the Budget + +All execution tiers (Ignition, Sparkplug, Maglev) decrement the interrupt budget at strategic points: + +* **Loop Back-Edges**: To detect hot loops. +* **Function Returns**: To detect frequently called functions. + +### Ignition (Interpreter) +In `src/interpreter/interpreter-assembler.cc`, Ignition decrements the budget in `DecreaseInterruptBudget` which is called by `JumpBackward` (for loops) and `UpdateInterruptBudgetOnReturn` (for returns). + +### Sparkplug (Baseline) +In architecture-specific files like `src/baseline/x64/baseline-assembler-x64-inl.h`, Sparkplug decrements the budget in `AddToInterruptBudgetAndJumpIfNotExceeded` (using negative weights) at returns and loop back-edges. + +### Maglev (Mid-Tier) +In Maglev IR, these are represented by nodes like `ReduceInterruptBudgetForLoop` and `ReduceInterruptBudgetForReturn`. + +### Example (Maglev x64) + +In `src/maglev/x64/maglev-ir-x64.cc`, the budget reduction is implemented by subtracting the amount from the `FeedbackCell`: + +```cpp +void GenerateReduceInterruptBudget(MaglevAssembler* masm, Node* node, + Register feedback_cell, + ReduceInterruptBudgetType type, int amount) { + MaglevAssembler::TemporaryRegisterScope temps(masm); + __ subl( + FieldOperand(feedback_cell, offsetof(FeedbackCell, interrupt_budget_)), + Immediate(amount)); + ZoneLabelRef done(masm); + __ JumpToDeferredIf(less, HandleInterruptsAndTiering, done, node, type); + __ bind(*done); +} +``` + +If the result of the subtraction is negative (`less`), it jumps to deferred code (`HandleInterruptsAndTiering`). + +## Handling the Interrupt + +When the budget is exceeded, V8 calls into the C++ runtime. Each tier has its own set of runtime functions: + +* **Ignition**: `Runtime::kBytecodeBudgetInterruptWithStackCheck_Ignition` and `Runtime::kBytecodeBudgetInterrupt_Ignition`. +* **Sparkplug**: `Runtime::kBytecodeBudgetInterruptWithStackCheck_Sparkplug` and `Runtime::kBytecodeBudgetInterrupt_Sparkplug`. +* **Maglev**: `Runtime::kBytecodeBudgetInterruptWithStackCheck_Maglev` and `Runtime::kBytecodeBudgetInterrupt_Maglev`. + +The "WithStackCheck" variants are typically used at loop back-edges to handle both interrupts (e.g., GC requests, debugging pauses) and stack limit checks simultaneously. + +All these runtime functions eventually call into the **`TieringManager`** via `TieringManager::OnInterruptTick`. + +## The Decision to Tier Up + +The `TieringManager` inspects the function's profiling data (feedback vector, invocation count, etc.) to make a decision: + +* It checks if the function is "hot" enough to warrant optimization. +* It decides which tier to target (e.g., if Maglev is enabled and the function is currently in Sparkplug, it might target Maglev). +* It queues the function for concurrent compilation in the background. + +Once the background compilation finishes, V8 updates the function's entry in the **JS Dispatch Table**. + +### JS Dispatch Table and Handles + +In modern V8 (especially with the V8 Sandbox enabled), a `JSFunction` does not directly point to its `Code` object. Instead, it contains a `JSDispatchHandle` (an index into the `JSDispatchTable`). + +* **Indirection**: The `JSDispatchTable` holds the actual pointer to the `Code` (and the entry point). +* **Update**: When tiering up, V8 does not modify the `JSFunction` object itself. Instead, it updates the entry in the `JSDispatchTable` pointed to by the function's handle. +* **Atomicity**: This allows atomic updates to the code entry point, ensuring thread safety and facilitating concurrent execution and tiering without complex locking on the function object itself. + +Future calls to the function will automatically use the new code because they go through the same dispatch handle. + +## On-Stack Replacement (OSR) + +OSR is a technique that allows V8 to switch execution from unoptimized code (Ignition) to optimized code (Maglev/TurboFan) **while the function is currently executing** (on the stack). + +### Why it's needed +If a function contains a very long-running loop but is otherwise not called frequently, the budget interrupt at the return point will not trigger optimization soon enough. The loop back-edge budget reduction handles this by triggering optimization while still in the loop. + +### How it works +1. **Detection**: When a loop back-edge budget reaches zero, V8 checks if OSR is appropriate. +2. **Compilation**: V8 compiles the function with Maglev or TurboFan, but targeting a specific loop header as the entry point instead of the normal function start. +3. **Replacement**: The interpreter stack frame is replaced with an optimized stack frame (frame reconstruction), and execution continues in the optimized code at the loop header. + +--- + +## See Also +- `src/maglev/maglev-compiler.cc`: Maglev compilation pipeline. +- `src/execution/tiering-manager.cc`: V8's tiering manager. diff --git a/deps/v8/docs/sandbox/architecture.md b/deps/v8/docs/sandbox/architecture.md new file mode 100644 index 00000000000000..8b6298d49fe651 --- /dev/null +++ b/deps/v8/docs/sandbox/architecture.md @@ -0,0 +1,79 @@ +# V8 Sandbox Architecture + +This document describes the architecture of the V8 Sandbox, a low-overhead, in-process sandbox designed to protect the rest of the process from typical V8 vulnerabilities. + +## Overview + +The V8 Sandbox restricts the code executed by V8 to a subset of the process's virtual address space (typically 1TB), called **the sandbox**. All untrusted V8 objects live inside this sandbox. If an attacker exploits a vulnerability to gain arbitrary read/write primitives, they are ideally confined to this sandbox and cannot corrupt memory outside of it. + +The sandbox works purely in software by converting raw pointers into either: +1. **Offsets** from the base of the sandbox. +2. **Indices** into out-of-sandbox pointer tables (similar to file descriptors in Unix). + +## Attacker Model + +The sandbox assumes that an attacker can: +* Arbitrarily and concurrently modify any memory **inside** the sandbox address space. +* Read memory outside of the sandbox (e.g., via side channels). + +The goal is to prevent the attacker from corrupting memory **outside** the sandbox. Any such corruption is considered a sandbox violation. + +## Core Mechanisms: Sandboxed Pointers + +To maintain isolation, V8 replaces raw pointers with specialized pointer types when referencing objects across the sandbox boundary or even within it for specific security properties. + +### 1. Pointers pointing into the Sandbox + +* **Compressed Pointer**: Stored as a 32-bit offset from the start of the 4GB heap area inside the sandbox. Always points into the sandbox. +* **Sandboxed Pointer**: Used for referencing larger areas like ArrayBuffer backing stores. It is stored as a 40-bit offset from the base of the sandbox, shifted to the left to guarantee it stays within the sandbox size when decoded. + +### 2. Pointers pointing outside the Sandbox + +To securely reference objects outside the sandbox, V8 uses indirection via pointer tables located outside the sandbox. An attacker can only modify the index (which is inside the sandbox), but the table itself is protected. + +* **External Pointer**: References non-V8 ("external") objects. It is an index into the **ExternalPointerTable (EPT)**. The EPT performs type checks on access to prevent type confusion attacks. +* **CppHeap Pointer**: References objects on the `CppHeap`. It is an index into the **CppHeapPointerTable**. It uses a different type tagging scheme supporting type hierarchies. +* **Trusted Pointer**: References a **TrustedObject** (see below) located in trusted space. It is an index into the **TrustedPointerTable (TPT)**. +* **Code Pointer**: A specialized trusted pointer that always points to a `Code` object, using the **CodePointerTable (CPT)**. This also directly provides the entry point for execution. + +### 3. Pointers strictly outside the Sandbox + +* **Protected Pointer**: Used only between `TrustedObjects` in trusted space. They are implemented as compressed pointers but relative to the trusted space base. Neither the pointer nor the object can be modified by an attacker. + +## External Pointer Table + +The `ExternalPointerTable` (EPT) is a fundamental component of the V8 Sandbox designed to provide memory-safe access to objects located outside the V8 heap (external pointers) from within the sandbox. + +### Key Security Mechanisms + +1. **Indirection via Handles**: + * Objects inside the sandbox do not store raw pointers to external objects. Instead, they store an `ExternalPointerHandle`, which is an index into the EPT. + * This prevents attackers from modifying a pointer in the heap to point to an arbitrary memory location. They can only point to entries already present in the table. + +2. **Type Tagging**: + * Each entry in the table consists of a pointer-sized word that includes the raw pointer, a marking bit, and a **type tag** (`ExternalPointerTag`). + * The tag is ORed into the unused upper bits of the pointer when it is stored. + * When the pointer is loaded, it must be untagged using the expected tag. If the specified tag does not match the actual tag of the entry, the resulting pointer will have invalid top bits and will cause a crash upon dereference. This prevents type-confusion attacks. + +3. **Temporal Memory Safety (Garbage Collection)**: + * The table is garbage-collected to ensure that entries either contain valid pointers to live objects or are invalidated. + * It uses a marking bit for tracking live entries. The GC sweeps the table, building a freelist from dead entries. + +4. **Managed Resources**: + * For external resources whose lifetime is tied to objects inside the V8 heap, the `ManagedResource` class provides a way to explicitly zap (invalidate) the table entry when the external resource is destroyed. This prevents dangling pointers and use-after-free vulnerabilities. + +### Caveats +* **LSan Mode**: When Leak Sanitizer (LSan) is active, the table uses "fat" entries (16 bytes) to store the raw pointer for LSan to see. **This mode is not secure** as it could allow bypassing type checks if an attacker can make a handle point to the raw pointer part of the entry. + +## Memory Spaces + +* **The Sandbox**: The large virtual address space reservation containing the standard V8 heap and all untrusted objects. +* **Trusted Space**: A separate heap space located **outside** the sandbox. It contains sensitive objects like bytecode containers and JIT metadata (`TrustedObject`). Attackers cannot directly write to this space. + +## File Structure +* `src/sandbox/`: Implementation of the sandbox. +* `src/sandbox/sandbox.h`: Main sandbox class and configuration. +* `src/sandbox/external-pointer-table.h`: External pointer table implementation. +* `src/sandbox/code-pointer-table.h`: Code pointer table implementation. +* `src/sandbox/trusted-pointer-table.h`: Trusted pointer table implementation. +* `src/sandbox/cppheap-pointer-table.h`: CppHeap pointer table implementation. diff --git a/deps/v8/docs/security/reproducing-bugs.md b/deps/v8/docs/security/reproducing-bugs.md new file mode 100644 index 00000000000000..4555e7f3041e16 --- /dev/null +++ b/deps/v8/docs/security/reproducing-bugs.md @@ -0,0 +1,26 @@ +# Reproducing Security Bugs + +V8 offers many different configurations and modes. +Not all bugs filed are actually security bugs. +This document describes some of the configurations that can help with identifying whether a bug is a vulnerability or just a regular correctness bug. + +## Regular security bugs + +Reproductions (POCs) should work on `d8`. +To help identify whether a bug is a valid vulnerability or a regular correctness bug, various flags are used to filter out configurations that are not relevant for security testing. + +The recommended way to verify if a bug is a security vulnerability is to run the reproduction with `--run-as-security-poc` in addition to any provided flags. +If the crash still occurs with this flag enabled, it is likely a valid security vulnerability (**Type=Vulnerability**). + +### Fine-grained control over configurations + +`--run-as-security-poc` implies the following flags, which can also be manually set to narrow down the problem space: + +- `--disallow-unsafe-flags`: By default, `d8` runs with a variety of flags that are considered unsafe in the context of security testing. +This flag disables them. +**Setting this flag is the bare minimum requirement for a bug to be considered a security bug.** +- `--disallow-developer-only-features`: Prevents the usage of features that are only available to developers. +- `--no-experimental`: Prevents the usage of experimental features that are not yet ready for shipping. +- `--fuzzing`: Enables internal fuzzing support. It is often used to expose edge cases. + +If a POC stops reproducing when any of the above flags are set, it is likely not a security bug (**Type=Bug**, **Security_Impact-None**). diff --git a/deps/v8/docs/security/triaging.md b/deps/v8/docs/security/triaging.md new file mode 100644 index 00000000000000..2b56db9ad97ee5 --- /dev/null +++ b/deps/v8/docs/security/triaging.md @@ -0,0 +1,128 @@ +# Security Bug Triaging + +V8 generally triages security bugs based on [Chromium's guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/security-labels.md). + +Google-only: The internal version of this document is available at [go/v8-security-gardening](http://goto.google.com/v8-security-gardening). + +## Labels and classifications + +These classifications refer to Buganizer which is the issue tracker used by Chromium. + +- **Type=Vulnerability**: Designates a security vulnerability that impacts users. +- **Severity**: Same as [Chromium's severities](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md). +- **Priority**: A priority that in general is at least the severity. +In certain circumstances, e.g., in-the-wild exploitation, we may raise the priority further. +- **Security_Impact-{Head, Beta, Stable, Extended, None}** hotlists: Derived from the milestones set in the **Found In** field, this hotlist specifies the earliest affected release channel. +Should not normally be set by humans, except in the case of **Security_Impact-None** (hotlistid: 5433277) which means that the bug is in a disabled feature, or otherwise doesn't impact Chrome: see the section below for more details. + +In addition, the following fields are set as part of triaging: +- **Found In**: Should point to the milestone this was discovered to be broken. +It is okay to just set to the current stable or extended stable milestone if unknown. +- **Introduced In**: Should point to the milestone this was introduced. +It is okay to be conservative if unknown, e.g., to assume that the bug was present when a feature was launched. + +### Sandbox bypasses + +V8 Sandbox bypasses are included in Chrome’s VRP. +A successful bypass must show write access outside of the sandbox. +Read access is not considered part of the attack model. + +These bugs are currently treated differently from regular security bugs. +Specifically, the following properties are different from regular security bugs: + +- **Severity**: S2 +- **Security_Impact-None** (hotlistid: 5433277) +- **v8-sandbox** (hotlistid: 4802478) + +## Reproducing security bugs + +Security bugs should have proof-of-concept reproductions (POCs) attached to them. +V8 currently still accepts bugs without a POC with the caveat that such bugs have a much higher chance of being dismissed quickly. +See [the detailed documentation](reproducing-bugs.md) for the various different configurations V8 can be put in. + +### Regular security bugs + +Bugs should reproduce on `d8` by providing `--run-as-security-poc` in addition to possibly other flags. +Additional stress flags may be passed and can be useful to trigger compiler tiering and garbage collection. +Bugs that only reproduce without `--run-as-security-poc` have a much higher chance of not being considered security bugs in the first place. +See the section below for common scenarios that lead to reclassifications. + +### Sandbox security bugs + +The same general principles apply to sandbox security bugs. +To ease classification, bugs should reproduce on `d8` by providing `--run-as-sandbox-security-poc` in addition to possibly other flags in the [sandbox testing environment](../../src/sandbox/README.md#testing). + +## Common cases for conditional features and code + +This section lists common triaging scenarios. + +### Bugs in code that is not experimental and is enabled by default + +Fields: **Type=Vulnerability**, **Security_Impact-{Head,Beta,Stable,Extended}** + +Rationale: Security bugs reachable through production code for regular users. + +### Bugs in code that is not experimental but not enabled by default + +Fields: **Type=Vulnerability**, **Security_Impact-None** + +Rationale: These bugs are in features that are generally complete and on the track of shipping at some point. +We encourage experimenting and finding bugs in those features. + +Note that **Severity** should still be set to the appropriate Severity (S0-S3) for **Security_Impact-None** issues, as if the feature were enabled or the code reachable. + +### Bugs in code guarded by experimental flags + +Fields: **Type=Bug**, **Security_Impact-None** + +Rationale: The flags and setups guard unfinished features that are explicitly not considered ready for fuzzing yet. +Flags often follow the naming of `--experimental-*` and imply the `--experimental` flag. +Sometimes these flags also have some experimental annotation in the flag descriptions. + +Note: If the flag is part of, e.g., `--future` or `--wasm-staging` then this signals that the flags are ready for fuzzing. +We don’t change the flag names in this case to avoid further churn in the codebase. + +### Bugs in developer flags such as `--trace-*` or flags that are clearly marked as unsafe + +Fields: **Type=Bug**, **Security_Impact-None** + +Rationale: Not reachable in production, as these flags are only used by developers. + +## Other common cases + +### `nullptr` (or close to `0`) dereference + +Fields: **Type=Bug**, **Security_Impact-None** + +V8 relies on `nullptr` dereferences to deterministically crash. + +### Bogus `DCHECK`s or reliable `CHECK` crashers + +Fields: **Type=Bug**, **Security_Impact-None** + +Rationale: These issues are not considered security vulnerabilities because the crashes either cannot happen in production builds (e.g., `DCHECK` failures, which are compiled out) or they result in a safe, deterministic crash (e.g., `CHECK` failures). +Invalid ("bogus") `DCHECK`s should still be fixed or removed. + +Note: `CHECK`s must not be behind special builds or phases, such as `--verify-*`. + +### Sandbox: Read-only bypasses + +Fields: **Type=Bug**, **Security_Impact-None** + +Rationale: Sandbox bypasses that only lead to read access outside of the sandbox are not considered security vulnerabilities for now. + +### Breakage through directly invoking internal runtime functions with `%`-syntax + +Runtime functions like `%IterableForEach()` are directly visible to JavaScript programs via `--allow-natives-syntax`. +The functions are not supposed to be tested this way, as they generally have pre- and post-conditions. +This can lead to crashes (e.g., [484110302](https://crbug.com/484110302)) when they are incorrectly used. +Such crashes are working as intended. + +Functions that are exposed under fuzzing are specified in [`Runtime::IsEnabledForFuzzing()`](https://source.chromium.org/search?q=Runtime::IsEnabledForFuzzing()&ss=chromium). +This function also mentions potential caveats that could still lead to crashes. +To make this clear, V8 will automatically remove any calls to unsupported functions when being invoked with `--fuzzing`. + +### Relying on broken snapshots to craft vulnerabilities + +V8 uses snapshots that are deserialized at startup. +These snapshots are fully trusted and outside of the attacker model, see the Chrome Security FAQ regarding [physically local attacks](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#why-arent-physically_local-attacks-in-chromes-threat-model). diff --git a/deps/v8/docs/snapshot/architecture.md b/deps/v8/docs/snapshot/architecture.md new file mode 100644 index 00000000000000..7ce536484db940 --- /dev/null +++ b/deps/v8/docs/snapshot/architecture.md @@ -0,0 +1,87 @@ +# V8 Snapshot and Serializer System + +To achieve fast startup times, V8 uses a **Snapshot** system. Instead of parsing and compiling the standard library and initializing the heap from scratch every time a new Isolate is created, V8 captures a snapshot of a fully initialized heap and persists it. + +When a new Isolate starts up, it simply restores the heap state from the snapshot, which is significantly faster. + +## Key Components + +### 1. `mksnapshot` + +`mksnapshot` is a standalone executable tool built during the V8 build process. +* **Purpose**: To run a minimal V8 instance, initialize the heap (including compiling builtins), and serialize the resulting heap state into a snapshot. +* **Output**: It generates C++ files containing the snapshot data as byte arrays, which are then compiled and linked directly into the V8 binary (or written to external files). + +### 2. Serializer and Deserializer + +The core logic for saving and restoring heap state is in the `Serializer` and `Deserializer` classes (in `src/snapshot/`). + +* **Serialization**: The process of traversing the heap graph and writing objects to a stream (`SnapshotByteSink`). + * It handles pointers by converting them to references (e.g., back references to already seen objects or roots). + * It uses specialized serializers for different spaces. +* **Deserialization**: The process of reading the byte stream and recreating the objects in the heap. + * It allocates objects and fills in their fields. + * It patches pointers based on the references in the stream. + +## Serialization Bytecode + +The snapshot data is not a raw memory dump. Instead, it is a stream of **bytecode instructions** that the `Deserializer` executes to reconstruct the heap. This design makes the snapshot format robust across different memory layouts and address spaces. + +> [!IMPORTANT] +> The serialization format is trusted and strictly build- and version-dependent. Code caches and snapshots include the V8 version and critical build flags as metadata. The deserializer will bail out and reject the snapshot if a mismatch is detected. + +The bytecode is defined in `src/snapshot/serializer-deserializer.h` (in `enum Bytecode`) and includes instructions for: +* **Object Allocation**: Instructions to allocate an object of a specific size in a specific heap space (e.g., `kNewObject`). +* **Reference Handling**: + * **Back References**: Pointing to an object already deserialized in the current stream. + * **Root References**: Pointing to a well-known object in the roots table (e.g., `kRootArrayConstants`). + * **Attached Objects**: References to objects provided externally to the deserializer. +* **Data Filling**: Copying raw data into the allocated objects. +* **Pointer Patching**: Instructions to resolve pointers between objects as they are created. +* **Repetition**: Optimizing for repetitive data (e.g., `kFixedRepeatRoot`). + +By using a bytecode interpreter for deserialization, V8 can handle complex object graphs and cyclic references efficiently during isolate startup. + +## Types of Snapshots + +V8 uses several distinct snapshots to organize heap data: + +### 1. Read-Only Snapshot +* **Purpose**: Contains objects that are immutable and shared across all Isolates (e.g., the `undefined` value, small integers, certain Maps). +* **Benefit**: These objects can be placed in a read-only memory region and shared directly, saving memory and avoiding the need for locks. + +### 2. Startup Snapshot +* **Purpose**: Contains the rest of the initial heap state needed to start an Isolate, excluding custom contexts. +* **Contents**: Includes builtins, initial symbols, and global objects. + +### 3. Context Snapshot +* **Purpose**: Contains the state of a fully initialized `NativeContext`. +* **Benefit**: Allows embedders (like Chrome or Node.js) to create snapshots of a context with their own specific APIs already initialized. + +### 4. Shared Heap Snapshot +* **Purpose**: Contains objects that should be in the shared heap in the shared Isolate during startup (e.g., for `--shared-string-table`). +* **Behavior**: When the shared heap is not in use, its contents are deserialized into each Isolate. + +## Code Serialization (Code Cache) + +Independent of the startup snapshot, V8 also uses serialization for **Code Caching**. +* **Purpose**: To cache the generated code (Ignition bytecode or machine code) for user scripts. +* **How it works**: When a script is run for the first time, V8 can serialize its `BytecodeArray` or optimized code and save it to disk. On subsequent loads, V8 can deserialize the code directly, bypassing parsing and compilation. +* **Files**: Managed by `CodeSerializer` in `src/snapshot/code-serializer.cc`. + +## Snapshot Compression + +V8 can compress the snapshot data to reduce the size of the binary or external snapshot files. +* **Implementation**: Managed by `SnapshotCompression` in `src/snapshot/snapshot-compression.h` & `.cc`. +* **Configuration**: Controlled by the `V8_SNAPSHOT_COMPRESSION` build flag. + +## File Structure + +* `src/snapshot/mksnapshot.cc`: Entry point for the snapshot creation tool. +* `src/snapshot/serializer.h` & `.cc`: Base classes for serialization. +* `src/snapshot/deserializer.h` & `.cc`: Base classes for deserialization. +* `src/snapshot/read-only-serializer.cc` & `read-only-deserializer.cc`: Serializer and deserializer for the read-only space. +* `src/snapshot/startup-serializer.cc` & `startup-deserializer.cc`: Serializer and deserializer for the startup heap. +* `src/snapshot/context-serializer.cc` & `context-deserializer.cc`: Serializer and deserializer for contexts. +* `src/snapshot/shared-heap-serializer.cc` & `shared-heap-deserializer.cc`: Serializer and deserializer for the shared heap. +* `src/snapshot/code-serializer.cc`: Serializer for code caching. diff --git a/deps/v8/docs/source-code.md b/deps/v8/docs/source-code.md new file mode 100644 index 00000000000000..cacbbe2402a028 --- /dev/null +++ b/deps/v8/docs/source-code.md @@ -0,0 +1,162 @@ +--- +title: 'Checking out the V8 source code' +description: 'This document explains how to check out the V8 source code locally.' +--- +This document explains how to check out the V8 source code locally. If you just want to browse the source online, use these links: + +- [browse](https://chromium.googlesource.com/v8/v8/) +- [browse bleeding edge](https://chromium.googlesource.com/v8/v8/+/main) +- [changes](https://chromium.googlesource.com/v8/v8/+log/main) + +## Using Git + +V8’s Git repository is located at , with an official mirror on GitHub: . + +Don’t just `git clone` either of these URLs! if you want to build V8 from your checkout, instead follow the instructions below to get everything set up correctly. + +## Instructions + +1. On Linux or macOS, first install Git and then [`depot_tools`](https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up). + + On Windows, follow the Chromium instructions ([for Googlers](https://goto.google.com/building-chrome-win), [for non-Googlers](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#Setting-up-Windows)) to install Git, Visual Studio, Debugging tools for Windows, and `depot_tools`. + +1. Update `depot_tools` by executing the following into your terminal/shell. On Windows, this has to be done in the Command Prompt (`cmd.exe`), as opposed to PowerShell or others. + + ``` + gclient + ``` + +1. For **push access**, you need to set up a `.netrc` file with your Git password: + + 1. Go to and log in with your committer account (usually an `@chromium.org` account). Note: creating a new password doesn’t automatically revoke any previously created passwords. Please make sure you use the same email as the one set for `git config user.email`. + 1. Have a look at the big, grey box containing shell commands. Paste those lines into your shell. + +1. Now, get the V8 source code, including all branches and dependencies: + + ```bash + mkdir ~/v8 + cd ~/v8 + fetch v8 + cd v8 + ``` + +After that you’re intentionally in a detached head state. + +Optionally you can specify how new branches should be tracked: + +```bash +git config branch.autosetupmerge always +git config branch.autosetuprebase always +``` + +Alternatively, you can create new local branches like this (recommended): + +```bash +git new-branch fix-bug-1234 +``` + +## Staying up-to-date + +Update your current branch with `git pull`. Note that if you’re not on a branch, `git pull` won’t work, and you’ll need to use `git fetch` instead. + +```bash +git pull +``` + +Sometimes dependencies of V8 are updated. You can synchronize those by running: + +```bash +gclient sync +``` + +## Sending code for reviewing + +```bash +git cl upload +``` + +## Committing + +You can use the CQ checkbox on codereview for committing (preferred). See also the [chromium instructions](https://chromium.googlesource.com/chromium/src/+/main/docs/infra/cq.md) for CQ flags and troubleshooting. + +If you need more trybots than the default, add the following to your commit message on Gerrit (e.g. for adding a nosnap bot): + +``` +CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel +``` + +To land manually, update your branch: + +```bash +git pull --rebase origin +``` + +Then commit using + +```bash +git cl land +``` + +## Try jobs + +This section is only useful for V8 project members. + +### Creating a try job from codereview + +1. Upload a CL to Gerrit. + + ```bash + git cl upload + ``` + +1. Try the CL by sending a try job to the try bots like this: + + ```bash + git cl try + ``` + +1. Wait for the try bots to build and you get an email with the result. You can also check the try state at your patch on Gerrit. + +1. If applying the patch fails you either need to rebase your patch or specify the V8 revision to sync to: + +```bash +git cl try --revision=1234 +``` + +### Creating a try job from a local branch + +1. Commit some changes to a git branch in the local repo. + +1. Try the change by sending a try job to the try bots like this: + + ```bash + git cl try + ``` + +1. Wait for the try bots to build and you get an email with the result. Note: There are issues with some of the replicas at the moment. Sending try jobs from codereview is recommended. + +### Useful arguments + +The revision argument tells the try bot what revision of the code base is used for applying your local changes to. Without the revision, [V8’s LKGR revision](https://v8-status.appspot.com/lkgr) is used as the base. + +```bash +git cl try --revision=1234 +``` + +To avoid running your try job on all bots, use the `--bot` flag with a comma-separated list of builder names. Example: + +```bash +git cl try --bot=v8_mac_rel +``` + +### Viewing the try server + +```bash +git cl try-results +``` + +## Source code branches + +There are several different branches of V8; if you're unsure of which version to get, you most likely want the up-to-date stable version. Have a look at our [Release Process](/docs/release-process) for more information about the different branches used. + +You may want to follow the V8 version that Chrome is shipping on its stable (or beta) channels, see . diff --git a/deps/v8/docs/stack-trace-api.md b/deps/v8/docs/stack-trace-api.md new file mode 100644 index 00000000000000..cff70dd091a98f --- /dev/null +++ b/deps/v8/docs/stack-trace-api.md @@ -0,0 +1,190 @@ +--- +title: 'Stack trace API' +description: 'This document outlines V8’s JavaScript stack trace API.' +--- +All internal errors thrown in V8 capture a stack trace when they are created. This stack trace can be accessed from JavaScript through the non-standard `error.stack` property. V8 also has various hooks for controlling how stack traces are collected and formatted, and for allowing custom errors to also collect stack traces. This document outlines V8’s JavaScript stack trace API. + +## Basic stack traces + +By default, almost all errors thrown by V8 have a `stack` property that holds the topmost 10 stack frames, formatted as a string. Here’s an example of a fully formatted stack trace: + +``` +ReferenceError: FAIL is not defined + at Constraint.execute (deltablue.js:525:2) + at Constraint.recalculate (deltablue.js:424:21) + at Planner.addPropagate (deltablue.js:701:6) + at Constraint.satisfy (deltablue.js:184:15) + at Planner.incrementalAdd (deltablue.js:591:21) + at Constraint.addConstraint (deltablue.js:162:10) + at Constraint.BinaryConstraint (deltablue.js:346:7) + at Constraint.EqualityConstraint (deltablue.js:515:38) + at chainTest (deltablue.js:807:6) + at deltaBlue (deltablue.js:879:2) +``` + +The stack trace is collected when the error is created and is the same regardless of where or how many times the error is thrown. We collect 10 frames because it is usually enough to be useful but not so many that it has a noticeable negative performance impact. You can control how many stack frames are collected by setting the variable + +```js +Error.stackTraceLimit +``` + +Setting it to `0` disables stack trace collection. Any finite integer value can be used as the maximum number of frames to collect. Setting it to `Infinity` means that all frames get collected. This variable only affects the current context; it has to be set explicitly for each context that needs a different value. (Note that what is known as a “context” in V8 terminology corresponds to a page or `