v8x

@bartlomieju: Following up on our exchange, I would offer to write a POC for js2wasm integration into v8x. Being an ahead-of-time compiler the expectation would be a smaller footprint and higher performance than QuickJS, allowing for denser packing and reduced runtime costs per function call. WebAssembly would add isolation ideal for a multi-tenant setup. After looking into it, the idea would be to compile TypeScript to WebAssembly directly, then precompile the .wasm module with Wasmtime to .cwasm for small footprint and fast cold starts and then measure the shared runtime and per instance footprint and performance compared to QuickJS. For even smaller footprint the IR could also be lowered to a native target, but WebAssembly's module sandbox is ideal for multi-tenant setups. Would that fit into your vision for v8x and how big is the current footprint and performance with QuickJS compared to V8? Are you running native QuickJS or a Wasm build and how do you isolate tenants from each other?

I've been trying to compile a minimal V8 shell to WASM. I have completed compilation once or twice, though the resulting WASM binary didn't work as expected. I'm talking about no QuickJS, no Deno core, just the raw V8 with a minimal, ideally user-defined shell. This is where I'm at now https://github.com/guest271314/v8/blob/wasm-build/.github/workflows/build-d8-wasm.yml https://github.com/guest271314/v8/actions I'm wondering if the Rust crate would make the process simpler?

Adds , a fourth backend. Draft-quality scaffold, not a working engine — 75 symbols implemented, 745 still stubbed. Why this one is different JSC, QuickJS and Hermes are interpreters: hand them a source string at runtime and they run it. Porffor is an ahead-of-time compiler — it lowers JS to C and hands that to a C compiler, with nothing interpreted or JIT-compiled. So cannot mean "compile this string now". It can only resolve source already compiled into the binary. That makes the target flattened bundles (a celld Wrangler bundle, a graph) rather than arbitrary runtime input — and it is the reason this is worth trying at all: it tests whether the "generated ABI is the portability boundary" claim holds against an engine with no runtime compiler. Build shape Follows the hermes spike: → pure-Rust stub backend, links with zero porffor dependency → build.rs runs over and links the emitted object There is no engine library to link against. We compile the runtime itself out of porffor — its heap, collector and builtins — via a new target on the porffor side. points at a porffor checkout (default ). is the ABI contract. Porffor only emits builtins a compilation actually references, so a builtin absent from the seed is absent from the linked object. Every entry costs binary size in every consumer, which is the one axis porffor is unambiguously winning on (~500 KB object for a broad builtin surface, vs ~1 MB for QuickJS static and ~48 MB for JSC). Handles Same problem QuickJS has — a porffor is , 16 bytes, not a pointer — so the same solution: handles are arena slots and the slot address is the v8 handle. The discipline differs. QuickJS arena slots own exactly one refcount. Porffor has a tracing collector, so slots must be GC roots. The arena lives on the porffor side and registers with the collector in whole blocks rather than per handle, so entering and leaving a scope costs no per-handle root bookkeeping. What works Isolate, handle scope, context, primitives, strings (including , zero-copy into porffor's heap — safe because the collector is non-moving and the handle roots the string), objects, , platform lifecycle. churns 20k allocations then forces a full GC and reads the handle back, which is the test that actually exercises the root-range wiring. Notes for review One isolate per process. Porffor emits a single global heap per binary, so isolate liveness is a process-wide , not per-thread. A second live isolate panics rather than silently sharing the heap. The smoke test serializes on its own lock instead of relying on . is reused from via — it has zero engine coupling (plain calloc/free plus the Rust allocator vtable), so a second copy would only drift. differs from the hermes generator in one way: it emits stubs for symbols implemented in link-gated files instead of dropping them outright. A symbol getting a real body for the first time therefore needs no hand-added gate. (The hermes carries a hand-written block to compensate for the old behaviour; porffor's copy has that block removed, with a comment explaining why.) Not wired into the CI matrix.** No — adding a fourth column to the dashboard felt like a separate decision. Happy to add it. Diff to existing files is purely additive and feature-gated: (+13), (+51), (+5). Nothing under or is modified. Depends on an unlanded porffor change needs a target in porffor that suppresses and emits a stable C ABI. That is not upstream yet — the stub-only build () is unaffected and works against any checkout. Next over . Porffor's side is already built (a whose call target is a C function pointer, dispatched through ), and it is what celld's 126 sites bind to.