Defines allocation, copy, pointer lifetime, deallocation, invalid-length handling, and the model-size constraint created by the current host-to-WASM transfer ABI.
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.
Allocation contract
alloc(len) creates a Vec<u8> with capacity len, forgets the vector, and returns its pointer. Zero-byte requests and requests above 134,217,728 bytes return a null pointer.
Host obligations
- Call
allocwith the exact byte length. - Create a fresh view over
exports.memory.buffer. - Copy exactly that many bytes at the returned offset.
- Call the target ABI function while the allocation is live.
- Call
dealloc(ptr, len)with the original pointer and capacity.
Why identity matters
dealloc reconstructs Vec::from_raw_parts(ptr, 0, len). A changed pointer or capacity violates the allocator contract. The JavaScript bootstrap follows the pairing through allocCopy and release.
Operational consequence
The current full-file model transfer cannot admit an artifact larger than 128 MiB, even if the browser and WASM instance have additional memory. Chunked or stream-owned admission requires a different ABI.
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?