Open peterhuene opened 3 years ago
Replying to https://github.com/bytecodealliance/wasmtime/pull/2518#issuecomment-792956929 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
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.
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.