Stream: git-wasmtime

Topic: wasmtime / issue #13744 Make a separate pool for page-siz...

Wasmtime GitHub notifications bot (Jun 26 2026 at 22:36):

chenyan2002 opened issue #13744:

Feature

Currently, each memory reserves a 4G virtual address space in the pooling allocator. But page-size-1 memories use bounds check, it doesn't need the guarded virtual reservation. We need a separate pool for page-size-1 memories, so that we can have a higher limit for max_memories_per_component, and don't run out of virtual address space.

Implementation

We can set two new limits: page_size_1_memory_max_size and max_page_size_1_memories_per_component. Use Memory::new_dynamic for allocating the page-size-1 memory, and don't put the allocation_index into the MemoryPoll.

Alternatives

We can create a dedicated memory pool for page-size-1 memory, something similar to TablePool. But we need to reserve instance_count * page_size_1_memory_max_size * max_page_size_1_memories_per_component virtual space. With the new_dynamic/malloc approach, we only consume virtual space for the live ones.

Wasmtime GitHub notifications bot (Jun 29 2026 at 13:00):

alexcrichton added the enhancement label to Issue #13744.

Wasmtime GitHub notifications bot (Jun 30 2026 at 19:19):

fitzgen commented on issue #13744:

Having a separate pool for page-size-1 memories seems reasonable to me, although I think we would probably want to preserve the existing shared-pool-for-all-memories behavior if a dedicated page-size-1 pool is not configured.

I don't think we want to use Memory::new_dynamic here though, as that will allocate memories on-demand rather than pooling them. So I think something more similar to the alternative you listed is probably what we want.

Wasmtime GitHub notifications bot (Jun 30 2026 at 19:20):

fitzgen added the wasmtime:pooling-allocator label to Issue #13744.

Wasmtime GitHub notifications bot (Jul 30 2026 at 19:56):

subotac commented on issue #13744:

I'd like to work on this and have audited the current pooling allocator. I plan to implement the dedicated path as a second optional MemoryPool (not Memory::new_dynamic), with zero guard/reservation, no MPK
striping, and the existing CoW/image/decommit lifecycle.

Before changing the public configuration, could you confirm the intended limit semantics?

1. Should the dedicated pool be enabled only when both page_size_1_memory_max_size and max_page_size_1_memories_per_component are configured, with partial configuration rejected?
2. What should determine its global slot count? The issue mentions instance_count * max_page_size_1_memories_per_component, but total_component_instances does not cover standalone core-module allocations. Should
this be derived from total_core_instances * max_memories_per_module, or should there be an explicit total_page_size_1_memories limit?

3. When enabled, should the existing total_memories, max_memory_size, and max_memories_per_component apply only to ordinary memories, while max_memories_per_module remains an aggregate VMContext limit?

Without the new settings, the current shared-pool behavior would remain unchanged.

Wasmtime GitHub notifications bot (Aug 24 2026 at 18:13):

fitzgen commented on issue #13744:

@subotac apologies for the delayed response.

I think we will want to split total_memories into total_page_size_1_memories and total_default_page_size_memories (feel free to bikeshed better names) which then allows us to have default values for the knobs you mention in (1) and directly answers (2) and (3).

I think we will want tota_page_size_1_memories to be 0 by default so that existing pooling allocator users don't start allocating a whole new memory pool that they aren't using in practice today.

Last updated: Aug 30 2026 at 09:07 UTC