chore: remove LinearMemory trait (#53)

Signed-off-by: Henry <mail@henrygressmann.de>

Author: explodingcamera

ARCHITECTURE.md

@@ -1,6 +1,6 @@
 # TinyWasm Architecture
 
-TinyWasm follows the general runtime model described in the [WebAssembly specification](https://webassembly.github.io/spec/core/exec/runtime.html). It is a stack-based interpreter with a compact internal bytecode, width-specific value stacks, and configurable linear-memory backends.
+TinyWasm follows the general runtime model described in the [WebAssembly specification](https://webassembly.github.io/spec/core/exec/runtime.html). It is a stack-based interpreter with a compact internal bytecode, width-specific value stacks, and a contiguous `Vec`-backed linear memory.
 
 ## Execution Pipeline
 
@@ -40,29 +40,20 @@ The default runtime remains safe Rust throughout rather than relying on unchecke
 
 SIMD instructions have a portable safe-Rust implementation built from fixed-size arrays and lane operations, relying on the compiler to auto-vectorize where possible. Generated code is inspected with `cargo asm`, and benchmarks determine where architecture-specific alternatives are worthwhile. WebAssembly targets use native SIMD intrinsics where available, while the optional `simd-x86` feature provides selected x86 implementations for operations where the generic code produces worse results.
 
-## Memory Backends
+## Linear Memory
 
-Linear memory is implemented through the `LinearMemory` trait. The backend is selected with `engine::Config::with_memory_backend()`.
+Linear memory is a contiguous `Vec<u8>` allocation owned by a `MemoryInstance`. The interpreter accesses it through the internal `MemoryStorage` type, a small concrete boundary that keeps the `Vec` representation out of the executor so an mmap-backed storage can be substituted later without touching load and store paths.
 
-`LinearMemory` exposes separate fixed-width read and write methods for 8-, 16-, 32-, 64-, and 128-bit accesses. A const-generic method would not be callable through a `dyn LinearMemory` trait object, so each width is an explicit vtable entry that backends can optimize independently.
+Fixed-width loads and stores use a single const-generic `read_fixed::<N>` / `write_fixed::<N>` pair rather than per-width vtable methods. Scalar operations reduce to an effective-address computation, a bounds check, a slice access, and a `from_le_bytes` / `to_le_bytes` conversion, with out-of-bounds construction kept on cold paths. Bulk operations such as `fill` and `copy_within` map directly to native slice methods.
 
-This flexibility has a measurable cost: guest loads and stores cross the `dyn LinearMemory` boundary, adding an indirect call and generally preventing the backend operation from being inlined into the interpreter. The fixed-width methods keep the work behind that boundary as small and specialized as possible.
+Memory growth keeps the Wasm page count and limits on `MemoryInstance`. Before memory or table backing storage is allocated or resized, the configured `ResourceLimiter` is consulted so a host can bound guest resource consumption. The limiter is shared across the stores created from one `Engine` and lives behind an `Arc`.
 
-Available backends:
-
-- `VecMemory` - contiguous `Vec<u8>` backing and the default backend.
-- `PagedMemory` - sparse chunk-based allocation, with untouched chunks left unallocated and growth avoiding relocation of one contiguous buffer.
-- `LazyLinearMemory` - serves zero-filled reads without allocation and creates the configured backend on the first mutation or growth.
-- Custom backends through `MemoryBackend::custom()`.
-
-`VecMemory` growth may reallocate, though operating-system allocators can often grow page-backed allocations without copying the full buffer. Applications on conventional operating systems should generally keep it unless sparse allocation or non-relocating growth is specifically needed. Bounded dynamic stacks and sparse paged memory trade some runtime overhead for a smaller initial footprint on embedded and other resource-constrained systems.
+For conventional operating systems, a future mmap-backed storage could reserve virtual address space and use guard pages to move more bounds enforcement to the operating system, reducing explicit checks in linear-memory hot paths. This is the same broad approach described in [Wasmtime's linear-memory architecture](https://docs.wasmtime.dev/contributing-architecture.html#linear-memory), where virtual-memory reservations and guard regions eliminate or deduplicate explicit bounds checks.
 
 ## Future Experiments
 
 Future work may explore additional dispatch and code-generation strategies, including Rust's experimental `loop_match` state-machine work, a tail-call-based interpreter once Rust's explicit tail-call support matures, more aggressive superinstruction fusion, top-of-stack register allocation, or optional JIT compilation.
 
-For conventional operating systems, a future `mmap`-based memory backend could reserve virtual address space and use guard pages to move more bounds enforcement to the operating system, reducing explicit checks in linear-memory hot paths. This is the same broad approach described in [Wasmtime's linear-memory architecture](https://docs.wasmtime.dev/contributing-architecture.html#linear-memory), where virtual-memory reservations and guard regions eliminate or deduplicate explicit bounds checks.
-
 ## Important Modules
 
 - [visit.rs](./crates/parser/src/visit.rs) - function-body operator lowering
@@ -71,4 +62,4 @@ For conventional operating systems, a future `mmap`-based memory backend could r
 - [instructions.rs](./crates/types/src/instructions.rs) - internal instruction set
 - [value_stack.rs](./crates/tinywasm/src/interpreter/stack/value_stack.rs) - width-specific stacks
 - [call_stack.rs](./crates/tinywasm/src/interpreter/stack/call_stack.rs) - call frame stack
-- [memory/mod.rs](./crates/tinywasm/src/store/memory/mod.rs) - memory backend trait and implementations
+- [memory/mod.rs](./crates/tinywasm/src/store/memory/mod.rs) - linear memory storage

CHANGELOG.md

@@ -17,6 +17,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Added `ValueLane` for mapping WebAssembly value types to their physical 32-bit, 64-bit, or 128-bit storage lane.
 - Added a `validate` feature to `tinywasm` and `tinywasm-parser` (enabled by default) to optionally skip wasmparser validation for faster parsing of trusted modules.
 - Added optional parse-time operand deduplication to reduce precompiled module and `.twasm` archive size.
+- Added a `ResourceLimiter` trait, configurable through `engine::Config::with_resource_limiter`, to bound guest memory and table allocation and growth.
 
 ### Changed
 
@@ -25,14 +26,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Typed function tuples now support up to 20 parameters or results. `WasmTupleChain` is deprecated. Use untyped functions for larger signatures.
 - Module types now use one dense recursive type space, while function types are resolved through `Function::ty(&Store)`.
 - Globals are stored in separate 32-bit, 64-bit, and 128-bit value lanes, avoiding tagged value conversion during guest execution.
-- `LinearMemory` mutation methods and custom memory-backend factories now return `Trap` errors so lazy backend failures can be propagated.
+- Linear memory now uses a single contiguous `Vec`-backed storage with const-generic fixed-width loads and stores.
+- Increased the minimum supported Rust version from 1.95 to 1.98.
 
 ### Fixed
 
 - Directly defined imports now reject handles from a different `Store`.
 - Tail calls to host functions now return directly to the caller frame.
 - Fixed Memory64 bulk-memory operations and optimized stores using the wrong value-stack lane.
-- Fixed `memory.init` bounds checks, operand lowering, and local-memory allocation analysis.
+- Fixed `memory.init` bounds checks and operand lowering.
 - Fixed Memory64 default limits and host-size handling, including 32-bit targets.
 
 ### Breaking Changes
@@ -44,6 +46,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Renamed `ModuleInstanceAddr` to `ModuleInstanceId`.
 - Removed `HostFunction::ty` and `WasmFunction::ty`. Use `Function::ty(&Store)` for runtime function types.
 - Changed `TableType::element_type` and `Element::ty` from `WasmType` to `RefType`, and replaced module `table_types` with `TableDefinition { ty, init }`.
+- Removed the pluggable memory backend system (`LinearMemory`, `MemoryBackend`, `VecMemory`, `PagedMemory`, `LazyLinearMemory`, and `Config::with_memory_backend`). Linear memory is always `Vec`-backed. To limit initial memory allocation and growth, configure a `ResourceLimiter` with `Config::with_resource_limiter`.
+- Removed the local-memory allocation analysis (`LocalMemoryAllocation` and `ParserOptions::optimize_local_memory_allocation`). Local memories are always allocated eagerly.
+- Removed `Config::with_trap_on_oom`. A `ResourceLimiter` can return a trap when rejecting a memory or table allocation or growth request.
+- `Table::grow` now returns `Result<Option<usize>>`, matching `Memory::grow`. Growth limits and allocation failures return `None`, while limiter-provided traps return an error.
 
 ## [0.10.0] - 2026-07-24
 

Cargo.lock

@@ -13,7 +13,7 @@ default-members = [".", "crates/parser", "crates/tinywasm", "crates/types"]
 [workspace.package]
 version = "0.11.0-pre.0"
 edition = "2024"
-rust-version = "1.95"
+rust-version = "1.98"
 repository = "https://github.com/explodingcamera/tinywasm"
 license = "MIT OR Apache-2.0"
 keywords = ["interpreter", "no-std", "tinywasm", "wasm", "webassembly"]
@@ -31,9 +31,9 @@ pretty_env_logger = "0.5"
 serde = { version = "1.0", features = ["derive"] }
 serde_json = { version = "1.0" }
 wasm-testsuite = { version = "0.7" }
-wasmparser = { version = "0.256", default-features = false }
-wast = "256"
-wat = "1.256"
+wasmparser = { version = "0.257", default-features = false }
+wast = "257"
+wat = "1.257"
 
 criterion = { version = "0.8", default-features = false, features = ["cargo_bench_support", "rayon"] }
 
@@ -57,10 +57,6 @@ name = "tinywasm"
 harness = false
 name = "tinywasm_modes"
 
-[[bench]]
-harness = false
-name = "memory_backends"
-
 [dev-dependencies]
 anyhow.workspace = true
 criterion.workspace = true

Cargo.toml

@@ -61,7 +61,7 @@ TinyWasm modules can be compiled to the internal `twasm` bytecode format, which
 
 With default features disabled, `tinywasm` depends only on `core`, `alloc`, and `libm`[^libm], making it usable in `no_std + alloc` environments.
 
-Use `Engine` and `engine::Config` when you need non-default runtime settings such as fuel accounting, stack sizing, memory backend selection, the GC collection threshold, or trap-on-OOM behavior.
+Use `Engine` and `engine::Config` when you need non-default runtime settings such as fuel accounting, stack sizing, or the GC collection threshold. A `ResourceLimiter` attached to the engine's config bounds guest memory and table allocation and growth and can trap rejected requests.
 
 [^libm]: [rust-lang/rust#137578](https://github.com/rust-lang/rust/issues/137578) — tracking issue for floating-point math support in `no_std`.