Mimalloc vs dlmalloc

[technopedi]

A multithreaded application is causing memory access out of bounds with Mimalloc , but doesn't cause any issue with any other allocator like dlmalloc. I have enabled pthreads as well. What could be the possible reason of same?

[sbc100]

It could be a bug in mimalloc, or it could be existing memory corruption bug doesn't show up except under certain memory layout conditions.

Can you try emmalloc? Can you try mimalloc + -fsanitize=address?

[technopedi]

I get issue in mimalloc with below stack. Can we say that memory was exhausted

[kripken]

An access out of bounds sounds like a bug in mimalloc or our port of it. Can you provide a testcase?

The bug could be related to memory being exhausted, if there is a code path that doesn't handle OOM properly.

[technopedi]

How can new give memory access out of bounds? Shouldn't it be coming when trying to access something out of buffer allocated?

[kripken]

A bug inside new itself could cause strange things like this. Without a testcase it's hard to say. But in general, you are right that the more likely reason for an access out of bounds is a read past a buffer size.

[technopedi]

I'm trying to figure out the best test case and reduce the application into this error.Because unfortunately the asan+mimalloc in my application is giving heap_buffer_overflow in starting on main itself, due to which unable to use asan to figure out memory access out of bounds issue. Meanwhile is it safe to assume that if list of heaps per thread is exhausted, then block->next will ideally return garbage value, resulting in memory access out of bounds?

[gozetor]

After switching to mimalloc, we started seeing the exact same problem - we are pretty sure that the reason is the memory exhaustion. We don't have the same issue with dlmalloc, but there is a very high overhead in our multithreaded app.
We think that the reason is that mimalloc does not free memory pages as aggressively.
Maybe there are some mimalloc settings that may improve that. I tried a few, but they don't change much.

[Markus87]

In a simple single thread test that allocates memory 10 MByte at a time I see with mimalloc I run out of memory at ~2920 MBytes allocated.
dlmalloc or emmalloc can allocate ~4090 MByte.
(Both have -sMAXIMUM_MEMORY=4GB)

This could just as well be the documented worst case performance of +25% memory: https://microsoft.github.io/mimalloc/bench.html

The emsdk version I used for the test was v4.0.0

With multithreading (23 threads):
mimalloc: ~2560 MByte (the overhead grows a little if more threads are involved)
emmalloc: ~4080 MByte
dlmalloc: ~4080 MByte

[daanx]

Hi -- this is Daan from mimalloc; just catching up on the issue @Markus87 raised. It looks like things are working better with v3 which is good to hear. Just wanted to remark that there have been a few important bug fixes so it would be good to merge from the latest dev3 (or when I make a fresh release). Let me know if there are specific things that would be helpful to have upstreamed in mimalloc.

I didn't read the full thread, but just to add: the default arena reserve on 32-bit is 128MiB and it doubles every 4 times (so the fifth arena will be 256MiB). Nowadays, if we fail at arena allocation, we will try with a small size again to prevent the issue raised above when reaching the 4GiB limit.

[Markus87]

It looks like the improvements are coming from the mimalloc update alone.
I used https://github.com/kleisauke/emscripten/tree/mimalloc-update-3.0.1 for testing, I was thinking the changes of #23037 were included. But that does not seem to be the case.

[kleisauke]

@kleisauke do you know when your change may land? Looks like it improves memory usage efficiency considerably.

AFAIK, there is not yet a non-alpha release of the dev3 branch, so let's wait for that first.

I was thinking the changes of #23037 were included. But that does not seem to be the case.

It looks like the changes in #23037 are no-op on mimalloc v3.0-alpha anyway, it needs probably(?) to be adjusted to:

--DMI_SEGMENT_SLICE_SHIFT=(12 + MI_INTPTR_SHIFT)
+-DMI_ARENA_SLICE_SHIFT=(12 + MI_SIZE_SHIFT)

(in case it's still relevant, it feels a bit dangerous to change these definitions)

[kleisauke]

the default arena reserve on 32-bit is 128MiB and it doubles every 4 times (so the fifth arena will be 256MiB). Nowadays, if we fail at arena allocation, we will try with a small size again to prevent the issue raised above when reaching the 4GiB limit.

Great! I think that would fix #23090. FWIW, on wasm32, the default arena reserve starts at 32MiB:
https://github.com/microsoft/mimalloc/blob/c820259f3b886062b29ff607dac00226eb3c93e3/src/arena.c#L283-L285

[daanx]

• I hope to release an bug fixed v3 soon
• It is indeed not necessary to change the MI_ARENA_SLICE_SHIFT anymore I think (otherwise, let me know of any issues)
• ha @kleisauke , you know mimalloc better than me :-) I see that indeed for a "non virtual reserve" system like wasm, the arena size indeed starts at 32 MiB so that is quite conservative. When reaching the memory limit (4GiB) it falls back to minimal arena sizes (which I think is 8MiB at a time).