Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pooling instance allocator: use natural alignment for instances in the pool #2715

Open
peterhuene opened this issue Mar 8, 2021 · 2 comments
Assignees
Labels
wasmtime Issues about wasmtime that don't fall into another label

Comments

@peterhuene
Copy link
Member

peterhuene commented Mar 8, 2021

Currently the pooling instance allocator page-aligns each instance in the pool.

This is unnecessary and can lead to wasting some space to alignment padding.

Instances can be aligned according to their natural alignment instead as the pooling instance allocator does not muck around with the backing pages for an instance like it does with the other resources.

@peterhuene peterhuene added the wasmtime Issues about wasmtime that don't fall into another label label Mar 8, 2021
@peterhuene peterhuene self-assigned this Mar 8, 2021
@alexcrichton
Copy link
Member

Replying to #2518 (comment) over here....

For tables you mention that decommit is needed, but that's just a fancy way to do memset with zeros, right? Is the kernel doing it for us that much faster than us doing it ourselves? (not sure if this was a bottleneck in lucet, for example).

For malloc/free as well I'm imagining that we'd malloc the whole pool and then do custom memory management within the pool itself FWIW, rather than using malloc/free for each individual instance and table.

My main thinking with using malloc/free is that it's just generally a bit more portable and helps us to work with any old chunk of memory rather than something that's specificall mmap'd

@peterhuene
Copy link
Member Author

peterhuene commented Mar 9, 2021

Correct, it's just a fancy way to memset for tables, so it can be replaced with that. It would certainly be worth benchmarking to see if managing the table pool is worth the added complexity. Lucet doesn't implement it this way since tables are read-only and part of the compilation artifact itself iirc (that is to say, tables are not a concern of the runtime).

Re: the portability issue, the pooling allocator needs the platform specific implementation anyway for managing the linear memory pool, so switching over the instance and table pools to malloc/free likely won't rid us of much platform-specific code.

Still, it can't hurt to investigate such a design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime Issues about wasmtime that don't fall into another label
Projects
None yet
Development

No branches or pull requests

2 participants