Stream: git-wasmtime

Topic: wasmtime / issue #5656 Always allocate `Instance` memory ...


view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2023 at 22:48):

github-actions[bot] commented on issue #5656:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2023 at 22:48):

github-actions[bot] commented on issue #5656:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html


<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

view this post on Zulip Wasmtime GitHub notifications bot (Feb 01 2023 at 17:54):

alexcrichton commented on issue #5656:

what is the point of pooling?

In my head the main purpose of pooling in Wasmtime is to reduce the impact of virtual memory management. Reusing slots allows memory image reuse possibly, reduction of page faults as memory is already paged in, etc.

Precisely how the pool is used I think is up to an application. For example an application may want a large pool for a smaller number of maximally concurrent instances to have as many affine slots per module as possible. In such a configuration it may not be expected to have such a large impact on RSS for idle slots doing nothing.

Overall I personally think it's pretty reasonable to expect that the working set consumed by wasmtime is roughly proportional to the working set of live objects in an embedding. While it's not strictly necessary that we malloc/free the instances here I don't think it necessarily hurts anyone.

The changes here can have other minor additional benefits such reducing fragmentation overhead since instances are allocated on page-aligned mappings today whereas with this PR they're thrown into the general malloc/free pool to get a better fit.


Last updated: Dec 23 2024 at 13:07 UTC