Wasmtime GitHub notifications bot (Mar 12 2026 at 21:26): Wasmtime GitHub notifications bot (Mar 12 2026 at 21:26):posborne opened PR #12768 from posborne:max-core-instances-aggregate-size-per-component to bytecodealliance:main:
There exist several knobs for limiting the memory that might be consumed for metadata for components. For core module instances within a component, the two that previously existed to control metadata allocations have been:
- A: max_core_instances_per_component
- B: component_instance_size
These allow for an embedder to set an upper bound on memory used by a component's instances to A * B. This value could be quite large for some systems and it would be nice to be able to set a cap on the total memory that might be used for metadata across all instances while still allowing for a greater number of instances with the potential for a subset of those instances to be relatively large.
To accommodate this, we add a new limit that tracks this aggregate measure.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Mar 12 2026 at 21:26):posborne requested pchickey for a review on PR #12768.
Wasmtime GitHub notifications bot (Mar 12 2026 at 21:26):posborne requested wasmtime-core-reviewers for a review on PR #12768.
Wasmtime GitHub notifications bot (Mar 12 2026 at 21:59):alexcrichton commented on PR #12768:
Thanks! And also, good idea!
WDYT about possibly avoiding a new configuration knob, however, and folding this into the calculation/limit of
component_instance_size? I'm wary of tying things too too deeply to exactly how things are implemented today, and I'm not sure there's too much need to consider the knobs separately vs being able to fold this into a preexisting knob.
Wasmtime GitHub notifications bot (Mar 12 2026 at 22:18):posborne commented on PR #12768:
WDYT about possibly avoiding a new configuration knob, however, and folding this into the calculation/limit of component_instance_size?
I like that idea and I think it probably provides the same coverage for the concerns embedders have related to limiting host memory used by components within the runtime and is one less internal concern to worry about.
I'll work on a new change with a patch that works in that way. With that, do you think we should increase the defaults all for
component_instance_size?
Wasmtime GitHub notifications bot (Mar 12 2026 at 22:29):alexcrichton commented on PR #12768:
The current default of 1M I feel is pretty generous for components as-is so lumping all the core modules into that as well I think is reasonable enough, but it's also pretty arbitrary so if you run into issues don't hesitate to raise it
Wasmtime GitHub notifications bot (Mar 12 2026 at 23:15):posborne closed without merge PR #12768.
Last updated: Mar 23 2026 at 16:19 UTC