Skip to content

Pooling allocator: switch to a struct-of-free-lists representation #6627

@fitzgen

Description

@fitzgen

Rather than our current free-list-of-structs representation.

That is, right now we have a single free list where each slot has space for the vmctx, table(s), memory(s), etc. This is wasteful in a component-model world, where each instance in the component is going to reserve a full pooling allocator slot of tables/memories/etc even if it is not using all of that state (e.g. the instance only imports memories).

If, instead, we had separate free lists for each of vmctxs, tables, memories, etc... then we can allocate the precise number of things that the component will use, without any slop.

This does mean that we will do len(vmctxs) + len(tables) + len(memories) + ... free list allocations rather than only len(instances). This is probably fine, however, because we can have a single mutex protecting all free lists rather than per-free-list locks, and the actual free list allocation is (probably?) pretty cheap in comparison to the locking involved. Note also that only the free list for memories cares about affinity, so we can use a simplified and optimized free list implementation for all other entities.

Metadata

Metadata

Assignees

Labels

performancewasmtimeIssues about wasmtime that don't fall into another labelwasmtime:apiRelated to the API of the `wasmtime` crate itself

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions