Live-alias WebAssembly.Memory.buffer to WAMR linear memory (browser-faithful detach-on-grow)

[e-fu]

Problem

master returns WebAssembly.Memory.prototype.buffer as a copy of WAMR's
linear memory (.slice().buffer). That breaks the browser contract that
mem.buffer aliases the live backing store: a host that writes through a
DataView/TypedArray over mem.buffer can't make those writes visible to the
guest, and a guest write isn't visible to a previously-handed-out view. The
concrete casualty is Go's wasm_exec.js, which caches a DataView over
mem.buffer and relies on host↔guest writes propagating through it.

Change

Live-alias Memory.buffer directly onto WAMR's linear memory, with browser-faithful semantics:

• Stable identity — repeated .buffer access returns the same ArrayBuffer
  while the backing store hasn't moved/resized.
• Detach-on-grow — WebAssembly.Memory.grow detaches the previously
  handed-out buffer on every call (including grow(0) and in-place growth),
  matching browsers; a fresh .buffer reflects the grown size.
• Mid-call grow safety — a guest memory.grow opcode inside a call moves
  the backing store; the cached alias is now invalidated at the JS host-import
  re-entry boundary (via a C-ABI seam exported from the root NIF module that
  reverse-maps the host exec_env's module instance to the owning instance), so
  a host callback never reads through a stale/dangling alias.
• Zero-page memory — (memory 0) now exposes a 0-length ArrayBuffer
  (new WebAssembly.Memory({initial: 0}).buffer) instead of throwing.
• TextDecoder.decode accepts a DataView (incl. non-zero byteOffset),
  with bounds-checking.

Tests

test/wasm_test.exs covers: host writes through a mem.buffer DataView are
visible to the guest; stable buffer identity until grow; detach-on-grow and
grow(0) detach; a buffer captured before an in-call grow is detached at the
next host re-entry; zero-page 0-length buffer; TextDecoder.decode of a
DataView.

Builds under the CI toolchain pin (OTP 27.0 / Elixir 1.18 / Zig 0.15.2); CI
runs the full suite.

[Copilot]

Pull request overview

This PR updates QuickBEAM’s WebAssembly polyfill/runtime integration to make WebAssembly.Memory.prototype.buffer a live alias of WAMR’s linear memory (browser-faithful), including detach-on-grow semantics and safety when memory.grow happens mid-call before host re-entry. It also enables WAMR bulk-memory opcode support and extends TextDecoder.decode to accept DataView, with new regression tests.

Changes:

• Live-alias Memory.buffer onto WAMR linear memory with stable identity, detach-on-grow, and host-import-boundary invalidation.
• Enable WAMR bulk-memory “_OPT” opcodes and add fixtures/tests to ensure they compile and run.
• Accept DataView in TextDecoder.decode (with bounds checking) and add workflow artifact uploads for easier branch testing.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test/wasm_test.exs	Adds regression fixtures and tests for bulk-memory opcodes plus Memory.buffer aliasing/detach semantics and TextDecoder DataView decoding.
priv/ts/webassembly.ts	Switches WasmMemory.buffer to a native-backed live buffer accessor instead of returning a copied buffer.
priv/c_src/wamr_bridge.h	Exposes new C bridge APIs to retrieve linear-memory base/size and the underlying module instance pointer.
priv/c_src/wamr_bridge.c	Fixes memory.grow semantics for WAMR and implements linear-memory base/size and module-inst accessors.
lib/quickbeam/wasm_js.zig	Implements cached, live-aliased ArrayBuffer creation/detachment, plus invalidation on grow and after calls.
lib/quickbeam/wasm_host_imports.zig	Adds a host-import boundary hook to invalidate/detach stale memory aliases before JS callbacks.
lib/quickbeam/wamr.zig	Enables WASM_ENABLE_BULK_MEMORY_OPT in the WAMR cImport configuration.
lib/quickbeam/text_encoding.zig	Extends TextDecoder.decode to accept DataView inputs correctly and safely.
lib/quickbeam/quickbeam.zig	Adds a root-module C-ABI export seam for alias invalidation reachable from host-import code.
lib/quickbeam/native.ex	Enables WASM_ENABLE_BULK_MEMORY_OPT in WAMR C flags and adds an opt-out for UBSan flags via env var.
.github/workflows/precompile.yml	Uploads build artifacts for all runs (not only tags) to support feature-branch testing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[e-fu]

Known limitation: guest-opcode memory.grow(0) and the mem.buffer alias

A cross-family (Codex) correctness review of this branch flagged one fidelity gap worth disclosing for a conscious accept/defer decision. No memory-safety issue — purely a deviation from the browser's "any grow detaches" contract.

The gap. Two paths invalidate the cached aliasing mem.buffer:

1. The JS WebAssembly.Memory.prototype.grow wrapper detaches unconditionally on every call (incl. grow(0)) — covered by the new regression tests.
2. The host-import boundary (invalidate_buffer_if_moved, reached before re-entering any JS host import) detaches only when the linear-memory base or size changed — the catch-all for a guest that grows memory via the raw memory.grow opcode, bypassing path 1.

A guest-side memory.grow(0) executed via the opcode leaves base and size unchanged, so path 2 does not detach the cached alias at the next host re-entry — unlike a browser, which detaches on any grow call.

Why this is not a safety bug. grow(0) allocates zero pages, so WAMR never reallocates the backing store; base/size are genuinely stable and the cached alias still points at valid, correctly-sized memory. There is no use-after-free or dangling pointer — only a semantic-fidelity deviation.

Why it isn't fixed inline here. The host-boundary hook runs before every JS host import. Making it detach unconditionally would destroy the zero-copy aliasing optimization (every host call would invalidate and force a mem.buffer re-fetch). A correct fix that preserves the optimization needs a dirty-flag set by the WAMR memory.grow opcode — a WAMR-internal grow hook, which felt like an architectural call for the maintainer rather than something to bake in silently with a performance tradeoff. The opcode grow(0) (vs. the JS Memory API) is also an uncommon guest pattern, so practical exposure is low.

Happy to implement the WAMR grow-hook approach if you'd prefer the contract fully honored — just let me know.

[dannote]

Thanks for the PR. I rebased and tested this locally, but the new live-buffer tests still hit the WAMR Debug/UBSan alignment panic and abort the BEAM.

Could you rework the tests/implementation so this path fails safely or avoids that WAMR panic? Also, please split the unrelated CI artifact and sanitizer-env changes out of this PR.

[e-fu]

Sorry for the very late reply — this dropped off my radar for far too long.

I'm closing this one. Three of the commits here have since landed on master independently (the WASM_ENABLE_BULK_MEMORY_OPT flag in both native.ex and wamr.zig, and the per-branch build-artifact upload in precompile.yml), and the branch is now ~140 commits behind across the Zig 0.16 / Platform / wasm_stack_size changes. The downstream consumer that motivated the live-alias work (a Go GOOS=js GOARCH=wasm signer) has since moved to a native Port helper, so I'm no longer in a good position to rebase this and — more importantly — to verify the result on a Linux build.

Rather than let it rot, one parting note that may be worth more than the PR itself: I think I found the root cause of the "pre-existing WAMR Debug/UBSan alignment trap" you worked around in wasm_test.exs.

priv/c_src/wamr/interpreter/wasm_interp_classic.c:6822:

frame_csp = frame->csp_bottom = (WASMBranchBlock *)frame->sp_boundary;

sp_boundary is a uint32 * (frame->lp + param_cell_num + local_cell_num + max_stack_cell_num), so it carries only 4-byte alignment. WASMBranchBlock (wasm.h:1183) is three pointers plus a uint32, i.e. _Alignof == 8 on 64-bit. Whenever param_cell_num + local_cell_num + max_stack_cell_num is odd, csp_bottom lands on a 4-byte boundary, and the first frame_csp->begin_addr = frame_ip (line 549) trips UBSan's alignment check.

That makes it deterministic per guest — a function of the callee's cell parity — rather than "on some builds", which would explain why only certain fixtures trigger it while add(40, 2) runs clean.

The fix should be to round csp_bottom up to 8 bytes and account for the padding in wasm_interp_interp_frame_size() (wasm_interp.h:87). I have not built or tested that, so please treat it as a lead rather than a patch — but if it holds, it would let you un-neuter the two bulk-memory tests and drop the csp_bottom caveat in the :wasm_stack_size tests.

Worth flagging separately: the live Memory.buffer issue itself is still open on master — the getter still returns .slice().buffer, i.e. a copy, so host writes through new DataView(mem.buffer) never reach the guest. Anyone is welcome to pick that up from this branch.

Thanks for the reviews here and on the earlier PRs.