V8
Author: Ludovic HENRY ludovic.henry@qti.qualcomm.com
Date: 2026-06-17
Scope: RISC-V (riscv64/linux) support status for V8
Audience: Technical leadership, resource allocation strategy
Verification policy: Every claim is cross-referenced to a primary upstream source. Items that could not be verified against a second source are marked [NEEDS VERIFICATION].
1. Project Overview
V8 is Google’s JavaScript and WebAssembly engine. It is the runtime inside Chromium/Chrome, Node.js, and Deno. V8 is not affiliated with any independent foundation. It is a Google-owned project, governed entirely by Google under a BSD 3-Clause license, using the Chromium OWNERS file model for distributed code review authority.
The canonical repository is at chromium.googlesource.com/v8/v8. The GitHub repository at v8/v8 is a read-only mirror. All contributions must go through Gerrit at chromium-review.googlesource.com.
V8’s RISC-V backend is community-maintained by engineers at ISCAS/PLCT Lab and, in an advisory capacity, by Kasper Lund at Meta. Google does not maintain the RISC-V backend.
2. Port History and Upstreaming Timeline
The RISC-V V8 port was initiated by Wei Wu (wuwei2016@iscas.ac.cn, ISCAS/PLCT Lab), who proposed upstreaming to the v8-dev mailing list on July 15, 2020. Prior to upstreaming, work existed in a community fork at github.com/isrc-cas/v8-riscv (later github.com/v8-riscv/v8), with an initial “helloworld” milestone running on QEMU Fedora RV64 in 2020. Two separate groups, ISCAS/PLCT Lab and FutureWei Technologies, merged their fork efforts before upstreaming.
The earliest commit in the upstream mirror with a [riscv64] label is commit 6d8e8ab dated March 12, 2021, authored by luyahan (Lu Yahan, ISCAS), at commit-position refs/heads/master@{#73370}. The RISC-V backend directories were first present in the tree in approximately December 2020 to March 2021.
Key early contributors: Lu Yahan (ISCAS, primary committer), Ji Qiu (ISCAS), Wei Wu (ISCAS, coordination), and a group of fork contributors including Xiaofang Zou, Jiayou Chen, Wenzhang Yang, and Liqiang Tao.
The 32-bit RISC-V (riscv32) port was deprecated in late 2025 and is scheduled for removal after May 2026. The stated reason: 32-bit RISC-V is primarily used in embedded systems without a Linux OS, but V8 requires Linux. Five of the twelve currently open issues in riscv-collab/v8 are labeled RV32G, consistent with the pending removal.
3. Upstream Support Tier
V8 uses a CI-presence-based support model, not named tiers. Per v8.dev/docs/ports, RISC-V is listed alongside MIPS, PPC, s390, and LoongArch as an “unofficially supported” port with a dedicated external team. The ports page states: “The Risc-V team will do the port. Contact/CC the Risc-V team in the CL if needed.” Contact email: v8-risc-v-ports@chromium.org.
This means:
- Google accepts RISC-V patches but does not commit to maintaining the backend.
- RISC-V breakages caused by upstream V8 changes are the responsibility of the RISC-V team (ISCAS/PLCT), not Google.
- There is no SLA, no rollback policy, and no Google engineer designated to handle RISC-V CI failures.
- Approximately 25% of all RISC-V V8 commits over the six months before December 2025 were purely tracking upstream changes, per the RISE blog post. This maintenance burden falls entirely on the ISCAS team.
The RISC-V OWNERS file (RISCV_OWNERS) lists three maintainers with approval rights over RISC-V subdirectories:
| Organization | |
|---|---|
| kasperl@meta.com | Meta (Kasper Lund, V8 co-creator) |
| qiuji@iscas.ac.cn | ISCAS / PLCT Lab (Ji Qiu) |
| yahan@iscas.ac.cn | ISCAS / PLCT Lab (Lu Yahan) |
Google’s core V8 team (COMMON_OWNERS, approximately 38 engineers, all at @chromium.org or @google.com) retains authority to require a second Code-Review+2 from a V8 owner for any RISC-V CL before merging. The Review-Enforcement submit requirement in Gerrit is the mechanism. Active CLs (e.g., CL 7953190) are blocked by this requirement when only a RISC-V OWNER (Ji Qiu) has given +1 and no broader V8 owner has given +2.
4. Technical Architecture and RISC-V-Specific Subsystems
V8 has four JIT tiers and a full interpreter. All four tiers have RISC-V backends.
4.1 Assembler Layer (src/codegen/riscv/)
58 files. The assembler is built as a multi-layer mixin hierarchy: AssemblerRISCVI (base integer) plus per-extension classes compose into Assembler, which composes into MacroAssembler. Each ISA extension has its own pair of header/source files.
ISA extensions with production assembler support: RV64I, RV32I, M, A, C, F, D, V (RVV, full coverage), Zba, Zbb, Zbs, Zfa, Zfh, Zicond, Zicsr, Zifencei, Zimop, Zicfiss (shadow stack).
The macro-assembler-riscv.cc is 283 KB, exceeding x64 (177 KB) and arm64 (181 KB). The RISC-V total codegen directory is 58 files vs 12 for x64 and 22 for arm64; the higher file count reflects the modular ISA extension design, not redundancy.
Extensions not present: Zbc (carry-less multiply), Zbkb. Zvfh (vector half-precision) is not present; f16x8 Wasm operations return false (stub). Zabha (byte/halfword atomics) has a TODO in liftoff-assembler-riscv64-inl.h but is unimplemented.
RVV implementation uses a custom C++ assembler wrapper layer. No vfloat32m1_t C intrinsics from rvv_intrinsics.h are used anywhere in the backend.
4.2 Turbofan JIT Backend (src/compiler/backend/riscv/)
7 files. instruction-codes-riscv.h (18 KB) defines the full IR opcode set with explicit TARGET_ARCH_OPCODE_LIST_ZBA and _ZBB sections and a large RVV SIMD opcode set. code-generator-riscv.cc (234 KB, vs 336 KB for x64 and 204 KB for arm64) emits machine code from selected opcodes, including full RVV SIMD via VU.SetSimd128 + vl/vs, Zba/Zbb/Zbs inline, and shadow stack (Zicfiss). instruction-selector-riscv64.cc (104 KB) performs opcode selection including Zba sh[1-3]add address folding and Zbb byte-swap.
The instruction scheduler (instruction-scheduler-riscv.cc, 38 KB vs 14 KB for x64/arm64) contains latency data that was copied from the MIPS port. This data is acknowledged as stale and is not accurate for any real RISC-V microarchitecture [NEEDS VERIFICATION: no Gerrit CL or public statement pinpointing this acknowledgment was found, though the MIPS-origin of the port is well-documented].
4.3 Liftoff WebAssembly Baseline JIT (src/wasm/baseline/riscv/)
3 files totaling approximately 273 KB (shared: 102 KB, riscv64-specific: 83 KB, riscv32-specific: 89 KB), larger than x64 (197 KB) and arm64 (174 KB), reflecting the extension modularization.
All RVV SIMD128 Wasm operations are implemented (vadd, vmul, vfadd, FMA, comparisons, shuffles, reductions, conversions). One confirmed stub: kF32LoadF16 (f16 memory load) is UNIMPLEMENTED(), intentionally disabled pending float16 support. Full LR/SC and AMO atomic suite present. Zabha (byte/halfword atomics) has a TODO(riscv): use Zabha instruction if enabled comment and falls back to a slower sequence.
4.4 Maglev Mid-Tier JIT (src/maglev/riscv/)
3 files. maglev-assembler-riscv.cc (27 KB) and maglev-assembler-riscv-inl.h (82 KB) are comparable in size to x64 (24 KB / 55 KB) and arm64 (27 KB / 61 KB). maglev-ir-riscv.cc (47 KB) compares directly to x64 (47 KB) and arm64 (48 KB). Content analysis found no missing core functionality, only optimization-quality TODOs (peephole multiplication, better deopt reasons).
The Maglev backend uses Zfa’s fcvtmod_w_d instruction as a fast path in maglev-assembler-riscv.cc.
4.5 Builtins (src/builtins/riscv/)
Single file at 210 KB, within 2% of x64 (215 KB) and arm64 (215 KB). Covers JS entry/exit trampolines, interpreter entry, generator resumption, OSR, Function.apply/call, Maglev/Baseline prologues. Uses Zicond (MoveIfZero) and Zicfiss (sspush_ra/sspopchk_ra) shadow stack stubs.
4.6 Simulator (src/execution/riscv/)
simulator-riscv.cc is over 10,000 lines and fully interprets all instructions including complete RVV vector decode (DecodeRvvIVV, DecodeRvvFVF, and related). Supports RV32/RV64, Zfh, Zfa, A (LR/SC + AMO), and conditional RVV.
Zicfiss (shadow stack): the hardware path in shadow-stack-riscv.cc is UNREACHABLE(). Only the simulator path is implemented, guarded by V8_ENABLE_RISCV_SHADOW_STACK. This means shadow stack cannot be used on real hardware.
A simulator bug was found during real-hardware testing: vector register save/restore around C++ function calls was incorrect, and the simulator did not catch it. The bug was found and fixed only through testing on physical hardware (reported in the December 2025 RISE blog post).
4.7 Regexp JIT (src/regexp/riscv/)
regexp-macro-assembler-riscv.h is 60 KB (vs 75 KB for x64, 81 KB for arm64). Includes RVV-accelerated paths using vrgather_vv and vfirst_m. Production-level content with full stack frame layout.
4.8 Deoptimizer (src/deoptimizer/riscv/)
ZapCode() is empty with // TODO(422364570): Support this platform. This same TODO exists across multiple non-primary architectures and is an optimization-quality item (stack poisoning for debugging), not a correctness gap.
4.9 Disassembler (src/diagnostics/riscv/)
disasm-riscv.cc at over 2,200 lines covers all extensions: RVV via DecodeVType, Zba/Zbb/Zbs, Zfa, Zfh, Zimop, Zicfiss. Unwinder present in unwinder-riscv.cc.
5. Build System, Cross-Compilation, and Toolchain
V8 uses GN + Ninja. There are no CMakeLists.txt files. There are no Dockerfiles for riscv64 in upstream repositories (v8/v8, chromium/src, riscv-collab/v8). No prebuilt sysroot CIPD package exists for riscv64; the sysroot is fetched as a tarball from Google Cloud Storage via build/linux/sysroot_scripts/install-sysroot.py --arch=riscv64. The sysroot is Debian Trixie (all other architectures use Bullseye).
Three GN toolchain targets are defined in build/toolchain/linux/BUILD.gn:
gcc_toolchain("riscv64"): GCC cross-compile withtoolprefix = "riscv64-linux-gnu". Used for nativetarget_cpu="riscv64" is_clang=falsebuilds.clang_toolchain("clang_riscv64"): Clang native foris_clang=true target_cpu="riscv64"builds.clang_v8_toolchain("clang_x64_v8_riscv64"): Simulator build,target_cpu="x64" v8_target_cpu="riscv64".
Simulator build (recommended for development, requires no cross-compiler):
tools/dev/gm.py riscv64.debug
tools/dev/gm.py riscv64.release
Or manually:
gn gen out/riscv64.debug --args='target_cpu="x64" v8_target_cpu="riscv64" is_debug=true v8_enable_slow_dchecks=true v8_optimized_debug=false'
ninja -C out/riscv64.debug d8 -j$(nproc)
Native cross-compiled build: Requires riscv-gnu-toolchain built from source (approximately 8 GB disk). The toolchain-installed prefix is riscv64-unknown-linux-gnu-; if it differs from the expected riscv64-linux-gnu-, update build/toolchain/linux/BUILD.gn accordingly. Key GN args: target_cpu="riscv64" v8_target_cpu="riscv64" is_clang=false use_custom_libcxx=false treat_warnings_as_errors=false.
Known exclusions:
_FORTIFY_SOURCEis explicitly disabled forcurrent_cpu == "riscv64"inbuild/config/compiler/BUILD.gn. Do not pass it manually.use_custom_libcxx=falseis required for GCC native builds.- No ASAN/TSAN/MSAN riscv64 CI configuration exists. Sanitizer builds are not officially supported on riscv64 in V8’s CI.
RISC-V extension GN args (from build/config/riscv.gni, all default to false):
| Arg | Description |
|---|---|
riscv_use_rvv |
Enable RVV |
riscv_rvv_vlen |
Simulator VLEN: 128/256/512/1024 (default 128) |
riscv_use_zba |
Zba |
riscv_use_zbb |
Zbb |
riscv_use_zbs |
Zbs |
riscv_use_zicfiss |
Shadow stack |
riscv_use_zicond |
Conditional ops |
6. Feature Coverage and Gap Analysis vs arm64 and amd64
6.1 JIT Tier Completeness
All four JIT tiers (Interpreter, Liftoff, Maglev, Turbofan/Turboshaft) have RISC-V backends. File sizes are within 20% of x64 and arm64 equivalents for every tier except the assembler layer, which is larger due to per-extension file decomposition.
The RISE December 2025 blog post describes RISC-V as “mostly at feature parity with officially supported architectures like x86_64 and ARM64” and “one of the most green ports” on V8’s buildbots. No numeric cross-architecture benchmark comparison is available in any public source as of June 2026.
6.2 Float16 / Zvfh
Float16 (f16x8) Wasm SIMD operations are currently disabled. f16x8 Liftoff ops return false (stub). CL 7953190 (open as of 2026-06-18) implements vfadd/vfsub/vfmul/vfdiv for fp16 using the Zvfh extension. Its prerequisite CL 7897892 (Zvfh simulator support) merged 2026-06-17. CL 7953190 is blocked only by the Review-Enforcement submit requirement (needs a V8 owner Code-Review+2 in addition to Ji Qiu’s +1).
6.3 Byte/Halfword Atomics (Zabha)
Liftoff (liftoff-assembler-riscv64-inl.h) has TODO(riscv): use Zabha instruction if enabled for byte and halfword atomic operations, which currently fall back to a slower sequence. No CL implementing Zabha was found in the research data.
6.4 Instruction Scheduler Latencies
The instruction scheduler’s latency table was ported from MIPS and does not reflect any actual RISC-V microarchitecture. This affects code quality for out-of-order cores where scheduling matters. The problem exists for all RISC-V targets but has no CL addressing it.
6.5 Zbb Rotation (rol/ror)
GitHub PRs #93 and #94 attempted to add ror/rol rotation instructions to the macro-assembler. Both were closed without merging due to a missing CLA, and because the GitHub mirror does not accept contributions. No equivalent Gerrit CL was found. The Zbb rotation optimization is absent from the RISC-V backend. CL 157c29e (merged 2026-05-08) enables Zba/Zbb/Zbs/Zicond for the rva23u64 profile target, but the rotation-specific macro-assembler paths are unimplemented.
6.6 Sub32 Overflow Bug
CL 7500131 (open since 2026-01-20, stalled) attempts to fix an acknowledged TODO in src/codegen/riscv/macro-assembler-riscv.cc around Sub32 handling of INT_MIN / immediate overflow in 32-bit integer subtraction. The CL has an unresolved inline review objection from Olivier Fluckiger (2026-01-21) stating the logic change is incorrect, and no test case demonstrating the bug has been provided. This is a latent correctness bug in the backend.
6.7 Zicfiss Shadow Stack
Hardware path is UNREACHABLE(). Only the simulator implements Zicfiss. No hardware-enabled shadow stack support exists.
6.8 Performance Optimizations Landed (from RISE Dec 2025 blog)
sh3add(Zba): address calculation reduced from 4 instructions to 2.zext.w(Zba): pointer decompression reduced from 5 instructions to 2. Authors describe this as “a nice and noticeable improvement.”- Atomic jump table patching: two-store
auipc+jalrreplaced with a single atomic memory load sequence, fixing a race condition in Wasm indirect function call patching. - Int32MultiplyOverflownBits: peephole using
Mul32 + srai(out, out, 32). - RVV vector width: expanded from 128-bit to 256-bit and 512-bit, which unblocked completion of the full JetStream benchmark suite.
6.9 JetStream Completion
V8 on RISC-V runs the full JetStream benchmark suite to completion (~33 MB Wasm bytecode, ~2 million lines of JavaScript). No numeric JetStream score for RISC-V is published in any public source. No Speedometer scores for RISC-V are published. No cross-architecture (RISC-V vs. x86_64 vs. ARM64) numeric comparison exists in any public source as of June 2026.
The only available numeric benchmark data is from the 2020 early-port era on HiFive Unleashed hardware (legacy Octane/SunSpider/Kraken benchmarks), showing near-parity with the simulator baseline. These numbers are not representative of current performance on any modern RISC-V microarchitecture.
6.6 Auipc+Jalr to Jal Optimization (stalled)
CL 6874383 (authored by Zhijin Zeng, SpacemiT; open since 2025-08-22, set to WIP 2026-02-03) replaces 2-instruction auipc+jalr sequences with single-instruction jal where the offset fits in 20 bits. A CQ dry run passed on 2025-09-17. The CL has been stalled for approximately 10 months due to an unresolved technical objection: the optimization changes the physical address of jump instructions, which breaks the safepoint table (which maps exact instruction offsets to GC metadata). A proposed fix using nop+jal to preserve the 2-instruction slot was suggested as a separate CL but has not been submitted.
7. CI/CD Infrastructure
7.1 Upstream LUCI CI
V8’s CI runs on Google’s LUCI infrastructure (ci.chromium.org), not GitHub Actions. The v8/v8 GitHub repository contains only one file in .github/: mistaken-pull-closer.yml, a bot that auto-closes PRs and redirects contributors to Gerrit. There are zero GitHub Actions workflow files in the repository.
RISC-V CI builders are defined in infra/testing/builders.pyl and infra/mb/mb_config.pyl. All official builders run on Ubuntu-22.04 x86-64 swarming workers using the simulator (no native hardware, no QEMU).
CI builders (luci.v8.ci, client.v8.ports group):
| Builder | Host | Test Shards | Hard Timeout |
|---|---|---|---|
| V8 Linux - riscv64 - sim | Ubuntu-22.04 x64 | 3 | 3600s |
| V8 Linux - riscv64 - sim - debug | Ubuntu-22.04 x64 | 6 | 3600s |
| V8 Linux - riscv64 - sim - pointer compression | Ubuntu-22.04 x64 | 3 | 3600s |
Try builders (luci.v8.try, tryserver.v8 group):
| Builder | Shards |
|---|---|
| v8_linux64_riscv64_dbg | 9 |
| v8_linux64_riscv64_rel | 4 |
| v8_linux64_riscv64_pointer_compression_rel | 4 |
No native (bare-metal) riscv64 builders exist in upstream V8 CI. The native (target_cpu="riscv64") GN configs in mb_config.pyl are under developer_default only, intended for local developer use.
7.2 Independent CI
An independent Jenkins buildbot at ci.rvperf.org/view/V8/ tests additional configurations: vlen128-riscv64, vlen256-riscv64, pointer-compression-riscv64, sandbox-riscv64, fastcheck-riscv32, fastcheck-riscv64, and a riscv64-jetstream job. This buildbot is maintained by the RISC-V community (PLCT Lab / rvperf.org), not Google. Numeric performance scores from this buildbot are not publicly exposed.
7.3 Simulator Fidelity Limitation
The simulator does not faithfully reproduce all hardware behaviors. A specific confirmed case: vector register save/restore around C++ function calls was incorrect, and the bug was found only on physical hardware, not in simulator CI. This means simulator-only CI gives false confidence for RVV-related code.
8. Distribution and Release Status
V8 has no standalone binary releases. The v8/v8 GitHub releases page is empty. V8 is distributed exclusively as source code, embedded in Node.js and Chromium/Chrome.
There is no riscv64 standalone V8 binary package in any major distribution under the name “v8”. The PyPI v8 package (version 0.1.5) is a source tarball with no architecture wheels and is unrelated to the Google V8 engine. The Debian v8 package does not exist (tracker.debian.org returns HTTP 404; buildd returns “No entry in riscv64 database” for all architectures).
The Debian package r-cran-v8 (R language bindings to V8) does have a riscv64 build in Debian sid at version 7.0.0+dfsg-2+b1. This package is not a standalone V8 binary; it is 268 KB of R glue code that depends on libnode137 (the Node.js shared library) on riscv64 as a proxy for V8. It does not provide a V8 binary or library usable outside the R ecosystem.
V8 is available for riscv64 as an embedded component of Node.js packages in Debian/Ubuntu and as part of Chromium builds.
9. Dependencies
9.1 libpfm4
Gap. V8 lists libpfm4 in its DEPS file for PMU-based profiling. The libpfm4 library has no RISC-V PMU event tables. The lib/events/ directory contains tables for AMD, Intel, ARM, and IBM Cell only. No RISC-V event table files exist, no tracked issues or PRs exist for riscv64 support, and no contribution is in progress. Hardware performance counter profiling workflows that depend on libpfm4 (including V8’s benchmark infrastructure) are completely blocked on riscv64. This requires a contribution to libpfm4 before V8 PMU profiling works on RISC-V hardware.
9.2 simdutf
Partial gap. simdutf (Unicode transcoding, used by V8’s string engine) builds with -march=rv64gcv but has no runtime dispatch for RVV. The extension requires an explicit compile-time flag; heterogeneous deployments cannot select RVV at runtime. One open correctness issue (#890, open as of research date): missing UTF-16 to UTF-8 length calculation with replacement for the RVV path. A history of correctness bugs found via fuzzing (issues #531-533, #728) indicates the RVV implementation has lower test coverage than scalar paths.
9.3 google/highway
Active issues. Three open issues affect riscv64: #2854 (mold-linker failure), #2793 (HwyDemoteTest failure on GCC 15), and #2738 (incorrect -march flag on RVA23 profile targets, which could cause incorrect optimization selection on newer RISC-V hardware). Highway is a dependency of simdutf, which is used by V8’s string engine. RVV CI for Highway is QEMU-based only.
9.4 abseil-cpp
Minor gap. CRC32C hardware acceleration is not implemented for riscv64. PR #1986 (hardware CRC32C for RISC-V) was open as of December 2025 and in progress. CRC32C falls back to software on riscv64. This affects V8’s hash table and CRC-dependent operations but is not a correctness issue.
9.5 Other Dependencies
- zlib (Chromium fork): Builds;
riscv_cpu_enable_rvvandriscv_cpu_enable_vclmuldetection flags present, butvclmuldetection is a TODO (not yet implemented). No dedicated riscv64 SIMD source files; only x86 and ARM have dedicated SIMD paths. - ICU: No riscv64-specific issues tracked. No blocking items.
- PartitionAlloc: No RISC-V-specific issues tracked. No RISC-V-specific spinlock tuning (uses same
kSpinCount = 64as all non-ARM64 targets). Pointer compression and MTE branches untested on riscv64. - fast_float: Builds; riscv64 CI added in 2021 (PRs #77/#78). Issue #343 (open as of December 2025): RVV vectorization not implemented, scalar-only performance.
- dragonbox: Architecture-agnostic C++ template library. No riscv64-specific issues.
- perfetto: Issue #936 (stack unwinding failure on riscv64) resolved November 2024. No currently open riscv64 issues.
- libc++/libc++abi/libunwind (LLVM): Available for riscv64 via LLVM 17+. No V8-specific blocking issues.
- temporal_capi (Rust):
riscv64gc-unknown-linux-gnutarget available since Rust 1.60 viarustup target add. No blocking issues.
10. Ecosystem Status
10.1 RISE Project Involvement
V8 has one documented touchpoint with the RISE project: a technical blog post titled “A Glimpse Into V8 Development for RISC-V” published December 9, 2025 at riseproject.dev, authored by Florian Loitsch (Rivos Inc.), Ji Qiu (ISCAS), Kasper Lund (Meta), Yahan Lu (ISCAS), and Zhijin Zeng (SpacemiT).
No RISE RFP number, grant identifier, or funded project is associated with V8. The post is a community contribution to the RISE blog, not a RISE-funded deliverable. V8 is absent from the RISE Python wheel builder (79 packages listed), the RISE runners user list (as of the May 2026 “six weeks in” post), and the RISE 2024 end-of-year funding recap. No V8 or JavaScript-related repository exists in the riseproject-dev GitHub organization (30 repos checked).
Google is a Premier Member of RISE (EUR 80,000/year, Governing Board representation). V8 indirectly benefits from Google’s RISE membership but has no direct RISE project.
10.2 RISE Premier and General Members Relevant to V8
Premier Members who invest in RISC-V silicon and may have direct interest in V8 performance: Alibaba Damo, Google, MediaTek, NVIDIA, Qualcomm, Red Hat, SiFive, Tenstorrent.
General Members who have directly contributed to V8 RISC-V: ISCAS / PLCT Lab (Ji Qiu, Lu Yahan; active RISC-V OWNERS), SpacemiT (Zhijin Zeng, CL 6874383 and documented optimizations).
10.3 Maintainer Concentration Risk
The entire V8 RISC-V backend is maintained operationally by two engineers at ISCAS/PLCT Lab (Lu Yahan and Ji Qiu). Lu Yahan is the dominant committer; in the commit log for April through June 2026, Lu Yahan authored 35 of the approximately 40 RISC-V commits visible in the research data. Kasper Lund (Meta) is listed as an OWNER and contributed simulator fixes in June 2025 [NEEDS VERIFICATION: the research data lists kasperl as active in June 2025 but does not enumerate specific CLs]. This is a single-team concentration risk.
11. Known Bugs and Active Issues
11.1 Open Issues in riscv-collab/v8 (June 2026)
| Issue | Title | Status |
|---|---|---|
| #705 | Tracking test262 and mozilla test status | Open, tracking |
| #704 | v8 run test failed | Open |
| #702 | rv32 debug stress mode failed | Open, RV32G (deprecation target) |
| #701 | Octane failed on Unmatched | Open, benchmark failure on real hardware |
| #696 | Record regression status for commit ddc083 | Open, regression tracking |
| #695 | cctest RunWasmLiftoff_I32Binop_DivS fails | Open, RV32G |
| #694 | How to cross compile v8 for riscv32 | Open, documentation |
| #670 | mjsunit/regress/regress-crbug-1041232.js fails on native | Open, RV32G |
| #669 | mjsunit/regress/regress-crbug-1209152.js fails on native | Open, RV32G |
| #666 | Test riscv32 native release | Open, RV32G |
| #630 | CompareI macro-assembler bug | Open, RV32G |
| #574 | Integer division by power of 2 should use shift | Open, optimization |
5 of 12 open issues are RV32G. Issue #701 (Octane failure on HiFive Unmatched) is the only open benchmark-specific failure on real riscv64 hardware. Issue #574 is the only open riscv64 performance optimization ticket. No NaN or floating-point correctness issues are open.
Note: The Chromium issue tracker (issues.chromium.org) requires authentication. No data from it was accessible during research. Upstream V8 bugs affecting riscv64 may exist there and are not reflected in this list.
11.2 Active Gerrit CLs of Note
| CL | Title | Status | Blocking Factor |
|---|---|---|---|
| 7953190 | [riscv] vfadd/vfsub/vfmul/vfdiv for fp16 | Open, 2026-06-17 | Needs V8 owner Code-Review+2 |
| 7203127 | [riscv][liftoff] Separate FP and SIMD registers | Open, stalled since 2026-03-12 | No reviewer LGTM; 3 months quiet |
| 7500131 | riscv64: Fix Sub32 immediate value handling | Open, stalled since 2026-01-21 | Unresolved correctness objection; no test case |
| 6874383 | [riscv] Replace auipc+jalr with jal | WIP since 2026-02-03, stalled | Safepoint table integrity concern |
| 7932348 | “fix” (WIP scratchpad) | Open, 2026-06-12 | No description, no reviewers; -2086 lines net |
12. Objections and Upstream Blockers
Q: Is the upstream maintainer team stable enough to depend on?
The functional V8 RISC-V backend is maintained by two engineers at ISCAS/PLCT Lab. There is no Google commitment to continuity. If the ISCAS team deprioritizes V8, the port degrades with each upstream change. The 25% tracking-overhead figure (from the RISE December 2025 blog post) quantifies this exposure: roughly one-quarter of all RISC-V V8 effort is consumed by chasing upstream changes, not producing new capability.
Q: Does the simulator give adequate confidence for production deployments?
No. The simulator failed to catch a real-hardware RVV register save/restore bug (reported in the December 2025 RISE blog post). All upstream CI is simulator-only. Organizations deploying V8 on physical RISC-V hardware need their own bare-metal or QEMU CI to validate correctness independently.
Q: Is the Sub32 overflow bug (CL 7500131) a production risk?
It is a latent correctness risk in 32-bit integer subtraction around INT_MIN boundary values. The CL acknowledging it has been stalled with an unresolved objection since January 2026. No test case demonstrating a failure has been contributed. The risk level cannot be quantified without a reproducer. This warrants investigation if V8 is used for arbitrary JavaScript execution on riscv64.
Q: Is there a path to official Google support for RISC-V?
Data not available: No public statement from Google’s V8 team on plans to officially support riscv64 was found. Google’s stated policy is that official support (CI bots blocking submission, Google engineers maintaining the backend) is reserved for architectures Google uses in production. No evidence that Google runs RISC-V hardware in production at the scale requiring V8 official support was found.
Q: Are there performance numbers for RISC-V vs. ARM64 or x86-64?
No cross-architecture numeric benchmark comparison (JetStream, Speedometer, or any other suite) is publicly available as of June 2026. JetStream suite completion on RISC-V is documented, but no score is published.
13. Investment Analysis
13.1 Functional Enablement
| Work Item | Effort (person-weeks) | Priority | Notes |
|---|---|---|---|
| Land CL 7953190 (fp16 vfadd/vfsub/vfmul/vfdiv) | 1 | High | CL is code-complete, CQ dry-run passed; blocked only on V8 owner +2 review. A reviewer with V8 owner status needs to engage. |
| Fix Sub32 overflow bug (CL 7500131) | 2 | High | Requires writing a test case demonstrating INT_MIN failure, addressing Olivier Fluckiger’s correctness objection, and re-uploading the patch. |
| Implement Zabha (byte/halfword atomics) | 3 | Medium | Remove the TODO in liftoff-assembler-riscv64-inl.h; implement Zabha instructions; requires hardware with Zabha to validate. |
| Implement Zbb ror/rol in macro-assembler | 2 | Medium | No Gerrit CL exists; prior attempt failed CLA check via wrong contribution channel. Straightforward instruction addition. |
| Harden shadow stack (Zicfiss hardware path) | 4 | Low | Current hardware path is UNREACHABLE(). Requires hardware with Zicfiss to test. Low priority until Zicfiss hardware is common. |
| Separate Liftoff FP and SIMD registers (CL 7203127) | 3 | Medium | CL is at PS16, CQ dry run passed. Stalled 3 months. Needs a reviewer to re-engage and a V8 owner LGTM. Correctness and ABI improvement. |
13.2 Performance Optimization
| Work Item | Effort (person-weeks) | Priority | Notes |
|---|---|---|---|
| Update instruction scheduler latency tables | 4-8 | Medium | Current tables are MIPS-derived. Requires latency characterization for at least one real RISC-V microarchitecture (e.g., SiFive P670 or comparable). Benefits out-of-order cores. |
| Land auipc+jalr to jal optimization (CL 6874383) | 2 | Medium | CQ dry run passed in September 2025. Stalled on safepoint concern. The nop+jal approach preserves safepoint structure and needs to be implemented as a separate CL per the reviewer’s suggestion. |
| Benchmarking infrastructure: establish riscv64 vs. arm64 baseline | 3 | High | No public numeric comparison exists. Cannot make evidence-based investment claims without this data. Requires bare-metal riscv64 hardware running JetStream and Speedometer with results published. |
| simdutf RVV runtime dispatch | 5 | Medium | This is a simdutf project issue, not a V8 issue directly, but it affects V8 string transcoding performance on heterogeneous deployments. Requires upstream simdutf contribution. |
13.3 CI/CD Infrastructure
| Work Item | Effort (person-weeks) | Priority | Notes |
|---|---|---|---|
| Bare-metal or QEMU riscv64 CI builder | 3 | High | All upstream CI is simulator-only. A real-hardware or QEMU CI builder would have caught the RVV register save/restore bug. Without it, every RVV patch is unvalidated against hardware. |
| Sanitizer builds (ASAN at minimum) | 4 | Medium | No ASAN CI exists for riscv64. ASAN would help find memory errors in the backend. Requires confirming ASAN support in Clang for riscv64 and creating a builder config. |
13.4 Ecosystem Enablement
| Work Item | Effort (person-weeks) | Priority | Notes |
|---|---|---|---|
| libpfm4: RISC-V PMU event tables | 6-10 | High | Zero RISC-V event tables exist in libpfm4. Profiling and benchmarking workflows that depend on hardware counters are completely blocked. Requires access to RISC-V PMU documentation for target silicon and upstream contribution to libpfm4. |
| simdutf: fix RVV correctness gap (#890) | 2 | High | Open correctness issue in UTF-16 to UTF-8 length calculation for RVV path. Affects V8 string transcoding correctness. Requires upstream simdutf contribution. |
| highway: fix -march RVA23 mismatch (#2738) | 2 | Medium | Incorrect march flag selection for RVA23 profile targets could cause wrong optimization selection on newer RISC-V hardware. Upstream highway contribution needed. |
13.5 Summary Table
| Area | Work Item | Effort (person-weeks) | Owner | Priority |
|---|---|---|---|---|
| Functional | Land CL 7953190 (fp16 SIMD arithmetic) | 1 | Any engineer with V8 owner status | High |
| Functional | Fix Sub32 overflow bug (CL 7500131) | 2 | RISC-V backend engineer | High |
| Functional | Implement Zabha byte/halfword atomics | 3 | RISC-V backend engineer | Medium |
| Functional | Implement Zbb ror/rol in macro-assembler | 2 | RISC-V backend engineer | Medium |
| Functional | Separate Liftoff FP and SIMD registers (CL 7203127) | 3 | RISC-V backend engineer + V8 owner reviewer | Medium |
| Functional | Harden Zicfiss hardware shadow stack | 4 | RISC-V backend engineer | Low |
| Performance | Establish riscv64 vs. arm64/x86-64 benchmark baseline | 3 | Performance engineer + hardware access | High |
| Performance | Update instruction scheduler latency tables | 4-8 | Microarchitecture engineer | Medium |
| Performance | Land auipc+jalr to jal optimization (CL 6874383) | 2 | RISC-V backend engineer | Medium |
| Performance | simdutf RVV runtime dispatch | 5 | simdutf upstream contributor | Medium |
| CI/CD | Bare-metal or QEMU riscv64 CI builder | 3 | Infrastructure engineer | High |
| CI/CD | ASAN sanitizer CI build | 4 | Infrastructure engineer | Medium |
| Ecosystem | libpfm4 RISC-V PMU event tables | 6-10 | PMU/hardware specialist | High |
| Ecosystem | Fix simdutf RVV correctness bug (#890) | 2 | simdutf upstream contributor | High |
| Ecosystem | Fix highway -march RVA23 mismatch (#2738) | 2 | highway upstream contributor | Medium |
14. Updates
No updates yet – initial report dated 2026-06-17.
15. References
- v8/v8 GitHub mirror
- v8.dev
- V8 ports documentation
- V8 RISCV_OWNERS file
- V8 COMMON_OWNERS file
- V8 src/codegen/riscv/
- V8 src/compiler/backend/riscv/
- V8 src/wasm/baseline/riscv/
- V8 src/maglev/riscv/
- V8 src/execution/riscv/
- V8 infra/testing/builders.pyl
- V8 infra/mb/mb_config.pyl
- RISE Project blog: A Glimpse Into V8 Development for RISC-V (Dec 2025)
- RISE Project members
- riscv-collab/v8 issue tracker
- Gerrit CL 7953190: fp16 vf* arithmetic
- Gerrit CL 7203127: Separate Liftoff FP and SIMD registers
- Gerrit CL 7500131: Fix Sub32 immediate handling
- Gerrit CL 6874383: auipc+jalr to jal
- GitHub PR #93 (Zbb rotation, closed)
- GitHub PR #94 (Zbb rotation, closed)
- V8 independent CI buildbot
- V8 official ports CI console
- simdutf issue #890 (RVV UTF-16 to UTF-8 length)
- google/highway issue #2738 (RVA23 -march mismatch)
- google/highway issue #2793 (GCC 15 test failure)
- google/highway issue #2854 (mold-linker failure)
- abseil-cpp PR #1986 (CRC32C hardware acceleration)
- fast_float issue #343 (RVV vectorization not implemented)