Stream: git-wasmtime

Topic: wasmtime / issue #11449 Expose pooling allocator runtime ...

Wasmtime GitHub notifications bot (Aug 18 2025 at 15:35):

lann opened issue #11449:

This is similar to #2640 but is about pull rather than push metrics.

The pooling allocator has a bunch of configurable limits. It can be difficult to understand the runtime behavior of a system to decide how to tune those limits, so it would be helpful to expose some runtime metrics to embedders.

For the API, we could crib from tokio with something like Engine::metrics(&self) -> RuntimeMetrics and RuntimeMetrics::pooling_allocator_live_core_instances(&self) -> u64.

I've been looking at the allocator code and I think I have a rough understanding of how to implement what I'm most interested in:

• live_core_instances and live_component_instances: these are already atomics so should be straightforward to report
• Used memory slots: I _think_ the used slot count can be derived from the stripe allocator(s). That approach would require taking a Mutex which seems OK in this context as long as metrics reporting frequency is limited. Alternatively the used slot count could be tracked separately in a new atomic.
• Used table slots: looks like the same story as MemoryPoll, potentially tracking via the allocator

Wasmtime GitHub notifications bot (Aug 18 2025 at 17:26):

alexcrichton commented on issue #11449:

Sounds like a very reasonable design to me! The only thing I'd to a minor bikeshed on is something like Engine::pooling_allocator_metrics(&self) -> Option<PoolingAllocatorMetrics> to handle the defaults-vs-pooling distinction. A general Engine::metrics could focus on generic things like instance count perhaps which makes sense to track for all allocators instead of just pooling.

Wasmtime GitHub notifications bot (Aug 22 2025 at 16:25):

alexcrichton closed issue #11449:

This is similar to #2640 but is about pull rather than push metrics.

The pooling allocator has a bunch of configurable limits. It can be difficult to understand the runtime behavior of a system to decide how to tune those limits, so it would be helpful to expose some runtime metrics to embedders.

For the API, we could crib from tokio with something like Engine::metrics(&self) -> RuntimeMetrics and RuntimeMetrics::pooling_allocator_live_core_instances(&self) -> u64.

I've been looking at the allocator code and I think I have a rough understanding of how to implement what I'm most interested in:

• live_core_instances and live_component_instances: these are already atomics so should be straightforward to report
• Used memory slots: I _think_ the used slot count can be derived from the stripe allocator(s). That approach would require taking a Mutex which seems OK in this context as long as metrics reporting frequency is limited. Alternatively the used slot count could be tracked separately in a new atomic.
• Used table slots: looks like the same story as MemoryPoll, potentially tracking via the allocator

Last updated: Dec 06 2025 at 06:05 UTC