emmalloc wastes memory with high alignments #20645
Comments
…20651) The new allocator can be used with -sMALLOC=mimalloc. On the benchmark added in this PR, dlmalloc does quite poorly here (getting actually slower with each additional core, because the lock contention is much larger than the actual work in the artificial benchmark). mimalloc, in comparison, scales the same as natively: more cores keeps helping. So mimalloc can be a significant speedup in codebases that have lock contention on malloc. mimalloc is significantly larger than dlmalloc, however, so we do not want it on by default. It also uses more memory, because of how mimalloc works and also due to #20645. Design-wise, this layers mimalloc on top of emmalloc. emmalloc functions as the "system allocator", which is more powerful than just using raw sbrk - sbrk can't free holes in the middle, for example. Code-wise, all of system/lib/mimalloc is unchanged from upstream (see README.emscripten) except for an ifdef or two, and then the new backend which is in system/lib/mimalloc/src/prim/emscripten/prim.c. That file has more comments explaining the design of the port. A new test is added which is also usable as a benchmark, test/other/test_mimalloc.cpp, which is where the numbers above come from. Fixes #18369
Take the alignment into account when requesting new memory from the OS. If the alignment is high then we need to ask for enough to ensure we end up aligned, or else we can end up allocating double the memory we need (see #20645). This only changes the amount we allocate from the OS if the alignment is non- standard, that is, this is NFC for normal calls to malloc. Also remove an assertion that limited the maximum alignment. mimalloc wants 4 MB alignment. Fixes #20654
Take the alignment into account when requesting new memory from the OS. If the alignment is high then we need to ask for enough to ensure we end up aligned, or else we can end up allocating double the memory we need (see emscripten-core#20645). This only changes the amount we allocate from the OS if the alignment is non- standard, that is, this is NFC for normal calls to malloc. Also remove an assertion that limited the maximum alignment. mimalloc wants 4 MB alignment. Fixes emscripten-core#20654
|
Was this fixed by #20704? This comment is still in |
|
Good catch, thanks @englercj ! Yes, this is basically fixed by that PR, aside from that one comment you noticed (unfortunately I don't think that remaining issue is fixable, as I think that high alignment is a design constraint of mimalloc). In fact it looks like I meant to close this by that PR, by had a typo in the issue number to be closed by it 😄 (20645/20654...) |
|
Awesome, thanks for the info! |
It looks like (that commit also seems to fix a suspicious OOM error on wasm-vips' benchmarks when switching the memory allocator from |
|
Interesting, thanks @kleisauke ! Good find. Do you have a sense of the tradeoffs there? I wonder if even smaller might make sense... |
FWIW, I just opened PR #23037 for this. |
Build with
and then edit
a.out.jsto add some logging at the top offunction sbrk:Running the program then shows
The initial sbrk is for emmalloc's internal data. Then we sbrk around 32MB, but then do so a second time for a total of 64MB.
This seems related to the high alignment, 1MB, as this does not happen without it.
This affects
mimallocwhen layered onemmalloc, sincemimallocdoes such large allocations with high alignment.The text was updated successfully, but these errors were encountered: