Stream: wasmtime

Topic: handling several small components

giovanni cristellon (Jan 08 2026 at 16:41):

hi, i was thinking of using wasm and wasmtime to allow users to implement their own custom extensions for my game, my concern tho is that by having potentially a lot of small mods this is going to mean that i get a ton of memory usage even if each one is doing relatively little, i was wondering what would be considered best practice in such a scenario to make so the mods are well isolated but minimize resource usage

fitzgen (he/him) (Jan 08 2026 at 18:40):

note that (by default, on 64-bit systems) Wasmtime will reserve large chunks of virtual memory in the process for each wasm linear memory, most of that is for guard pages, which never get backed by physical memory. additionally, only the memory pages that are actually touched by the wasm program will ever get backed by physical memory, and while that is potentially every page in the wasm linear memory in theory, many pages within the wasm linear memory never tend to get touched in practice.

but if you are concerned about virtual memory reservations, you can always do things like disable guard pages (at the cost of slowing down wasm execution because explicit bounds checks will be added to each load/store, instead of relying on the guard pages to catch out-of-bounds accesses)

you can also validate/enforce memory limits on plugins, either by

• statically enforcing a limit via parsing the wasm and checking the number of memories it has and the maximum limit on each memory
• dynamically enforcing a limit via a wasmtime::ResourceLimiter (or ResourceLimiterAsync)

Victor Adossi (Jan 09 2026 at 08:27):

To expand on what was already covered above -- you'll likely benefit from perusing the wasmtime::Config struct

For example the memory_guard_size option which relates directly to the explanation above (it's not the only related option but is well documented like the others).

Also, there's a question of what the WebAssembly binaries are written in -- when building WebAssembly components from scripting languages (e.g. Javascript, Python) there is often a large overhead as each binary contains a copy of the runtime. There are a few ways to overcome that size limit, with varying levels of difficulty. One of the easier ways is to change the plugin binaries that users pass around to actually contain just some chunk of code (assuming your dynamic language Wasm toolchain supports eval), and then keep a pool of one or more components that contains the engine.

There are other ways but that's probably the easiest one to grok (well, other than requiring a language that produces smaller WASM binaries).

Do you by any chance have some numbers around the resource usage and what stage at which it becomes problematic (during executions? steady state?)

giovanni cristellon (Jan 09 2026 at 12:54):

for now i am purely at an exploratory stage and trying to make sure i don't start with an architecture that is not suited for i want to do so i don't have benchmarks yet

Last updated: Jan 09 2026 at 13:15 UTC