bytecodealliance / bytecodealliance/wasmtime
Pooling allocator: investigate combining separate mmaps into one (unified per-instance) slot
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 126
Description
After some discussion with @alexcrichton just now, the question of why wasmtime's pooling allocator maintains separate pools for memories, tables, and instance structs (and stacks, but those are special on Windows at least) arose.
Especially if we're considering using `madvise` to flash-clear state and make instantiation faster, it might make sense to investigate whether we can "transpose" the arrangement and put all of an instance's resources in one contiguous region (with appropriate guards of course).
For example, one instance slot could contain all of that instance's tables and memories, and the `Instance` struct, and perhaps the stack on non-Windows platforms.
The major advantage of this is that we can decommit (flash-clear) the whole region with one `madvise` syscall. In contrast, today, we need a separate `madvise` for each resource. This cost is somewhat hidden today because we write ~every byte of the `Instance` and the tables (with eager init) but if we lazily initialize state in tables and/or `Instance`s (e.g. lazy anyfunc init) this could matter more.
Contributor guide
Assessment
This issue has not been assessed yet.