-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Pooling allocator: switch to a struct-of-free-lists representation #6627
Description
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.