Stream: git-wasmtime

Topic: wasmtime / issue #3759 memfd: Some minor follow-ups

Wasmtime GitHub notifications bot (Feb 02 2022 at 21:41):

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

Subscribe to Label Action

cc @peterhuene

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

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

• peterhuene: wasmtime:api

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

Learn more.
</details>

Wasmtime GitHub notifications bot (Feb 02 2022 at 21:46):

cfallin commented on issue #3759:

Re: pooling allocator on-by-default, I wonder if we should evaluate the default limits at the same time? IIRC, for example, a build of SpiderMonkey/WASI doesn't fit within the defaults; when testing with the pooling allocator I've had to bump the limits. One advantage of the on-demand allocator is that since it does a heap allocation just once, for just the right amount of VMContext space, it doesn't need to be as careful; while the pooling allocator can easily mmap significant amounts of memory for instances if it makes too-conservative assumptions.

(Perhaps a way around that is for the pooling allocator defaults to allow for very large instances -- as high as, say, what a typical browser would have for implementation-defined limits -- but only one instance slot?)

Wasmtime GitHub notifications bot (Feb 02 2022 at 22:06):

alexcrichton commented on issue #3759:

That makes sense to me, but to clarify the pooling allocator is already enabled by default, this shouldn't change that. I do think it's reasonable to up the limits though (or measure the impact of malloc-ing the VMContext instead of mmap-ing it to avoid the need for most limits)

Wasmtime GitHub notifications bot (Feb 02 2022 at 23:15):

cfallin commented on issue #3759:

That makes sense to me, but to clarify the pooling allocator is already enabled by default, this shouldn't change that

Even for wasmtime-cli though? I was referring to your third commit, which I think changes this -- that's the part I'd worry about potentially surprising someone who's using wasmtime to run big modules from the commandline...

Wasmtime GitHub notifications bot (Feb 03 2022 at 15:17):

alexcrichton commented on issue #3759:

Oh I see it's in a somewhat inconsistent state right now I think. The pooling allocator is enabled on the wasmtime crate unconditionally but the top-level feature is disabled by default. In any case I think that it's best to defer the limits question to later, AFAIK this is mostly just used for our own internal testing right now since there's not really much purpose for using the pooling allocator on the CLI anyway. It should be pretty easy to tweak the limits in the future if necessary.

Last updated: Nov 22 2024 at 17:03 UTC