bytecodealliance / bytecodealliance/wasmtime

Pooling allocator: investigate combining separate mmaps into one (unified per-instance) slot

Open
#3,754 4 comments 0 reactions 0 assignees View on GitHub
wasmtime
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.