Wasmtime GitHub notifications bot (Mar 08 2021 at 21:59): Wasmtime GitHub notifications bot (Mar 08 2021 at 21:59):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.
Wasmtime GitHub notifications bot (Mar 08 2021 at 21:59):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.
Wasmtime GitHub notifications bot (Mar 08 2021 at 21:59):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.
Wasmtime GitHub notifications bot (Mar 08 2021 at 22:00):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.
Wasmtime GitHub notifications bot (Mar 08 2021 at 23:21):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
memsetwith 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
Wasmtime GitHub notifications bot (Mar 09 2021 at 03:15):peterhuene commented on Issue #2715:
Correct, it's just a fancy way to
memsetfor 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.
Wasmtime GitHub notifications bot (Mar 09 2021 at 03:16):peterhuene edited a comment on Issue #2715:
Correct, it's just a fancy way to
memsetfor 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.
Wasmtime GitHub notifications bot (Mar 09 2021 at 03:17):peterhuene edited a comment on Issue #2715:
Correct, it's just a fancy way to
memsetfor 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/freelikely won't rid us of much platform-specific code.Still, it can't hurt to investigate such a design.
Last updated: Nov 22 2024 at 16:03 UTC