JavaScript-to-WASM memory transfer

Explains allocation ownership, full-file copies, UTF-8 prompt transfer, output views, deallocation, the 128 MiB cap, and implications for model growth.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Explains allocation ownership, full-file copies, UTF-8 prompt transfer, output views, deallocation, the 128 MiB cap, and implications for model growth.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Transfer contract

The host calls alloc(length), creates a Uint8Array view over exported WASM memory, copies bytes at the returned pointer, invokes the Rust operation, then calls dealloc(pointer, length).

Allocator implementation

Rust creates a Vec<u8> with requested capacity, forgets it, and reconstructs it during deallocation. Raw slice helpers reject null pointers, zero lengths, and transfers larger than 128 MiB.

Model-loading cost

The browser first holds the fetched ArrayBuffer, then copies the entire artifact into WASM linear memory, after which Rust creates runtime-owned tensor storage. Peak loading memory therefore exceeds artifact size and can include both packed source bytes and decoded f32 tensors.

Current hard boundary

A single transfer cannot exceed 134,217,728 bytes. The checked-in 68,194,944-byte f32 TinyLM-16M artifact fits; larger models require a new chunked or host-backed loader ABI rather than raising the cap blindly.

Required next design

Introduce chunk handles, bounded append/write operations, SHA-256 state, cancellation, finalization, and transactional model activation. Avoid retaining stale JavaScript views after WASM memory growth.

Scope

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations

  • Identify the source, version, target environment, and owner.
  • Separate observed values from estimates and externally reported values.
  • Record trade-offs, unsupported cases, and fallback behavior.
  • Link performance statements to a compatible benchmark methodology.

Verification questions

  • What exact artifact, revision, backend, and environment were reviewed?
  • Which assumptions could change the result?
  • Which data should be retained so another engineer can reproduce the conclusion?