emmalloc wastes memory with high alignments

[kripken]

#include <emscripten/emmalloc.h>
#include <stdio.h>

int main() {
  // Allocate 32MB with 1MB alignment.
  printf("%p\n", emmalloc_memalign(1024 * 1024, 32 * 1024 * 1024));
}

Build with

./emcc a.c -sMALLOC=emmalloc -sWASM=0 -sINITIAL_MEMORY=128mb --profiling

and then edit a.out.js to add some logging at the top of function sbrk:

 function sbrk($0) {
  console.log('sbrk', $0);

Running the program then shows

sbrk 48
sbrk 33554480
sbrk 33554480
0x100000

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 mimalloc when layered on emmalloc, since mimalloc does such large allocations with high alignment.

[englercj]

Was this fixed by #20704?

This comment is still in main so I wasn't entirely sure.

[kripken]

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...)

[englercj]

Awesome, thanks for the info!

[kleisauke]

This comment is still in main so I wasn't entirely sure.

It looks like MI_SEGMENT_ALIGN will affect this. I was able to halve that alignment by reducing the page size from 32KiB to 16KiB on wasm32, see for example:
kleisauke@20c3153
microsoft/mimalloc#647 (comment)

(that commit also seems to fix a suspicious OOM error on wasm-vips' benchmarks when switching the memory allocator from dlmalloc to mimalloc)

[kripken]

Interesting, thanks @kleisauke ! Good find.

Do you have a sense of the tradeoffs there? I wonder if even smaller might make sense...

[kleisauke]

I'm not sure if there are any trade-offs, but it feels a bit dangerous to change these definitions.

Upstream mentions that the dev-slice branch has improved this, so perhaps we could sync with that. I just opened (draft) PR #21548 for this.