WasmPageAllocator #3830
WasmPageAllocator #3830
Conversation
fengb
force-pushed
the
wasm-page-allocator
branch
2 times, most recently
from
aedfa7c to
036b90f
Compare
fengb
force-pushed
the
wasm-page-allocator
branch
from
036b90f to
45e0441
Compare
|
Did a bit of a spirit journey for the scanning algorithm: https://github.com/fengb/bitscan It seems like naive iteration + a bit of block skipping is the fastest and smallest, and has more opportunities for bit tuning.
|
| @@ -763,7 +872,7 @@ test "ArenaAllocator" { | |||
| try testAllocatorAlignedShrink(&arena_allocator.allocator); | |||
| } | |||
|
|
|||
| var test_fixed_buffer_allocator_memory: [80000 * @sizeOf(u64)]u8 = undefined; | |||
| var test_fixed_buffer_allocator_memory: [800000 * @sizeOf(u64)]u8 = undefined; | |||
There was a problem hiding this comment.
This broke alignment because 32 * page_size is a lot bigger in wasm land.
| try testAllocatorAlignedShrink(allocator); | ||
| if (!std.Target.current.isWasm()) { | ||
| try testAllocatorLargeAlignment(allocator); | ||
| try testAllocatorAlignedShrink(allocator); |
There was a problem hiding this comment.
This tests a new alignment of 32 * page_size.
fengb
force-pushed
the
wasm-page-allocator
branch
from
c12b5cb to
e91522b
Compare
| @@ -721,12 +802,46 @@ test "c_allocator" { | |||
| } | |||
| } | |||
|
|
|||
| test "WasmPageAllocator internals" { | |||
There was a problem hiding this comment.
I just realized this test can easily fail if any other file depends on page_allocator. Unfortunately, it looks pretty deep into the internal (unresetable) global state to make sure things are sane.
I have a few ideas to make this less dependent on existing behavior, but it'll have to assume total control of all global memory. Maybe that's okay?
There was a problem hiding this comment.
I think PageAllocator assuming total control of all wasm-intrinsically allocated memory is a reasonable design choice.
There was a problem hiding this comment.
I rewrote these tests to have much fewer assumptions on the internals. There's a hard dependency on ~270 MB of execution memory but I don't think it's too bad since it'll be reused.
|
A few thoughts related to tuning:
|
One option is to support a config option in the root source file. Idea being you could opt out of free, making the implementation of free a no-op. With #2292, this would set |
Closes #3789
import— this is an internal detail of LLVM, plus having variable page size leads to unpredictable performance and behavior__heap_baseproperly