peterhuene assigned Issue #2715 (assigned to peterhuene):
Currently the pooling instance allocator page-aligns each instance in the pool.
This is unnecessary and can lead to wasting a 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 labeled Issue #2715 (assigned to peterhuene):
Currently the pooling instance allocator page-aligns each instance in the pool.
This is unnecessary and can lead to wasting a 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 opened Issue #2715 (assigned to peterhuene):
Currently the pooling instance allocator page-aligns each instance in the pool.
This is unnecessary and can lead to wasting a 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 edited Issue #2715 (assigned to peterhuene):
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.
alexcrichton commented on Issue #2715:
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
peterhuene commented on Issue #2715:
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 likely won't rid us of much platform-specific code.
Still, it can't hurt to investigate such a design.
peterhuene edited a comment on Issue #2715:
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 likely won't rid us of much platform-specific code.
Still, it can't hurt to investigate such a design.
peterhuene edited a comment on Issue #2715:
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.
Last updated: Dec 23 2024 at 12:05 UTC