Update mimalloc to 3.3.0 by kleisauke · Pull Request #26696 · emscripten-core/emscripten

kleisauke · 2026-04-16T08:30:21Z

Resolves: #23090.
Supersedes: #23037.
Supersedes: #24542.

See: llvm/llvm-project@ea58410

This reverts commit a4e07d4. In preparation for the next commit.

sbc100 · 2026-04-16T15:45:40Z


-This contains mimalloc 8c532c32c3c96e5ba1f2283e032f69ead8add00f (v2.1.7) with
+This contains mimalloc 0ddf397796fbefa35b3278bd4431c2913a9892eb (v3.3.0) with
 Emscripten-specific changes.


Are we tracking these emscripten-specific changes?

Was it easy enough for you to port them to the new version?

Emscripten-specific changes are tracked in commit 8f4d480, which was created via:

Replace system/lib/mimalloc/ with original mimalloc v2.1.7.

Commit those changes.

Upgrade to mimalloc v3.3.0.

Revert the changes from step 2.

Nice. I wonder if its worth forking mimalloc in the emscripten-core org like we do for llvm and musl in order to keep track of these changes.

Perhaps not worth it as the changes are so small and we have the option to upstream most of them (I think?)

It's probably not worth creating a fork for these small changes. The changes to src/prim/emscripten/prim.c could likely be upstreamed, but I'm less certain about those in ‎src/alloc-override.c (although commit microsoft/mimalloc@a9b895e introduced a similar Emscripten-specific change to that file). I attempted to revert those weak decls with commit a4e07d4 but it was needed for test_wrap_malloc_mimalloc.

Commit 9e64b24 may also qualify as an Emscripten-specific change, but I'm not sure whether it should be documented (I've opened PR microsoft/mimalloc#1264 for this).

sbc100 · 2026-04-16T15:46:18Z

@@ -8654,8 +8654,7 @@ def test_mallinfo(self):
  @parameterized({
    '': ([],),
    'emmalloc': (['-sMALLOC=emmalloc'],),
-    # FIXME(https://github.com/emscripten-core/emscripten/issues/23090)
-    # 'mimalloc': (['-sMALLOC=mimalloc'],),
+    'mimalloc': (['-sMALLOC=mimalloc', '-sABORTING_MALLOC=0'],),


Why is ABORTING_MALLOC=0 needed here bit not for the other variants of this test?

It was somehow necessary for wasm64_4gb.test_wrap_malloc_mimalloc. mimalloc was likely over-allocating internally, and this change prevented an abort().

Maybe worth a TODO to investigate?

Added a TODO comment with dcf3cfd.

sbc100 · 2026-04-16T15:47:24Z

+    # https://github.com/emscripten-core/emscripten/issues/20645#issuecomment-1962964755
+    '-DMI_ARENA_SLICE_SHIFT=(12 + MI_SIZE_SHIFT)',
+    # `malloc`ed pointers must be aligned at least as strictly as max_align_t
+    '-DMI_MAX_ALIGN_SIZE=8',


Is this somehow not the default?

It's not the default. See:

emscripten/system/lib/mimalloc/include/mimalloc/types.h

Lines 35 to 39 in 094d31e

// Minimal alignment necessary. On most platforms 16 bytes are needed

// due to SSE registers for example. This must be at least `sizeof(void*)`

#ifndef MI_MAX_ALIGN_SIZE

#define MI_MAX_ALIGN_SIZE 16 // sizeof(max_align_t)

#endif

I synced this with:

emscripten/system/lib/emmalloc.c

Lines 74 to 77 in 094d31e

// Configuration: specifies the minimum alignment that malloc()ed memory outputs. Allocation requests with smaller alignment

// than this will yield an allocation with this much alignment.

#define MALLOC_ALIGNMENT alignof(max_align_t)

static_assert(alignof(max_align_t) == 8, "max_align_t must be correct");

Can we patch emscripten/system/lib/mimalloc/include/mimalloc/types.h to use alignof(max_align_t) directly maybe? Do you know why it doesn't already? Maybe because its C11?

But we could use the __alignof GCC/clang builtin when available?

How about:

#ifndef MI_MAX_ALIGN_SIZE #ifdef __GNUC__ #define MI_MAX_ALIGN_SIZE __alignof__(max_align_t) #else #define MI_MAX_ALIGN_SIZE 16 // sizeof(max_align_t) #endif #endif

?

MI_MAX_ALIGN_SIZE is also used in pre-processor checks, which prevents the use of function-like macros (such as _Alignof(), __alignof__() or alignof()), see:

emscripten/system/lib/mimalloc/src/page-queue.c

Lines 24 to 32 in 094d31e

#if (MI_MAX_ALIGN_SIZE > 4*MI_INTPTR_SIZE)

#error "define alignment for more than 4x word size for this platform"

#elif (MI_MAX_ALIGN_SIZE > 2*MI_INTPTR_SIZE)

#define MI_ALIGN4W // 4 machine words minimal alignment

#elif (MI_MAX_ALIGN_SIZE > MI_INTPTR_SIZE)

#define MI_ALIGN2W // 2 machine words minimal alignment

#else

// ok, default alignment is 1 word

#endif

sbc100 · 2026-04-16T15:48:23Z

+    '-DMI_MAX_ALIGN_SIZE=8',
+    # reserve memory in 64 MiB chunks (internally divided by 4)
+    # Note: keep in sync with the -sINITIAL_HEAP default
+    '-DMI_DEFAULT_ARENA_RESERVE=65536',


Is this number if kb ?

It's in KiB.

emscripten/system/lib/mimalloc/src/options.c

Line 148 in 094d31e

{ MI_DEFAULT_ARENA_RESERVE, MI_OPTION_UNINIT, MI_OPTION(arena_reserve) }, // reserve memory N KiB at a time (=1GiB) (use `option_get_size`)

emscripten/system/lib/mimalloc/include/mimalloc.h

Line 463 in 094d31e

mi_option_arena_reserve, // initial memory size for arena reservation (= 1 GiB on 64-bit) (internally, this value is in KiB; use `mi_option_get_size`)

The / 4 happens here:

emscripten/system/lib/mimalloc/src/arena.c

Lines 319 to 321 in 094d31e

if (!_mi_os_has_virtual_reserve()) {

arena_reserve = arena_reserve/4; // be conservative if virtual reserve is not supported (for WASM for example)

}

sbc100 · 2026-04-16T15:49:43Z

    # build mimalloc with an override of malloc/free
    '-DMI_MALLOC_OVERRIDE',
    # TODO: add build modes that include debug checks 1,2,3
    '-DMI_DEBUG=0',
    # disable `assert()` in the underlying emmalloc allocator
    '-DNDEBUG',
-    # avoid use of `__builtin_thread_pointer()`
-    '-DMI_LIBC_MUSL',
+    # enable use of `__builtin_thread_pointer()`


Why did this change from avoid => enable? Is it somehow OK to use now?

It can be enabled after commit llvm/llvm-project@ea58410.

sbc100 · 2026-04-16T15:50:07Z

    # build mimalloc with an override of malloc/free
    '-DMI_MALLOC_OVERRIDE',
    # TODO: add build modes that include debug checks 1,2,3
    '-DMI_DEBUG=0',
    # disable `assert()` in the underlying emmalloc allocator
    '-DNDEBUG',
-    # avoid use of `__builtin_thread_pointer()`
-    '-DMI_LIBC_MUSL',


We are using musl so wouldn't we want to continue to define this?

The MI_LIBC_MUSL definition is only used by:

emscripten/system/lib/mimalloc/include/mimalloc/prim.h

Lines 252 to 265 in 094d31e

// Do we have __builtin_thread_pointer? This would be the preferred way to get a unique thread id

// but unfortunately, it seems we cannot test for this reliably at this time (see issue #883)

// Nevertheless, it seems needed on older graviton platforms (see issue #851).

// For now, we only enable this for specific platforms.

#if !defined(__APPLE__) /* on apple (M1) the wrong register is read (tpidr_el0 instead of tpidrro_el0) so fall back to TLS slot assembly (<https://github.com/microsoft/mimalloc/issues/343#issuecomment-763272369>)*/ \

&& !defined(__CYGWIN__) \

&& !defined(MI_LIBC_MUSL) \

&& (!defined(__clang_major__) || __clang_major__ >= 14) /* older clang versions emit bad code; fall back to using the TLS slot (<https://lore.kernel.org/linux-arm-kernel/202110280952.352F66D8@keescook/T/>) */

#if (defined(__GNUC__) && (__GNUC__ >= 7) && defined(__aarch64__)) /* aarch64 for older gcc versions (issue #851) */ \

|| (defined(__GNUC__) && (__GNUC__ >= 11) && defined(__x86_64__)) \

|| (defined(__clang_major__) && (__clang_major__ >= 14) && (defined(__aarch64__) || defined(__x86_64__)))

#define MI_USE_BUILTIN_THREAD_POINTER 1

#endif

#endif

Looking at commit microsoft/mimalloc@e46c114 and the linked issue, I don't think it applies to Emscripten.

sbc100 · 2026-04-16T17:25:02Z

Thanks for working on this!

Lgtm but let's wait for @kripken to chime in

kleisauke added 7 commits April 16, 2026 10:16

Update mimalloc to 3.3.0 (microsoft/mimalloc@0ddf397)

ee253d1

mimalloc: add Emscripten-specific changes

8f4d480

mimalloc: enable use of __builtin_thread_pointer()

57a6623

See: llvm/llvm-project@ea58410

mimalloc: remove weak decls

a4e07d4

mimalloc: disable large pages by default

0719860

mimalloc: halve the page size

6b83c90

mimalloc: ensure proper alignment

a8cb678

This was referenced Apr 16, 2026

[mimalloc] Halve the page size #23037

Closed

Update mimalloc to 2.2.4 #24542

Closed

[do not merge] Test suite with mimalloc #24539

Draft

mimalloc: fix single-threaded build

9e64b24

kleisauke mentioned this pull request Apr 16, 2026

Fix single-threaded Wasm build microsoft/mimalloc#1264

Open

kleisauke added 6 commits April 16, 2026 12:25

Rebaseline other.test_malloc_size_mimalloc* codesize expectations

ddd3840

Revert "mimalloc: remove weak decls"

02d918b

This reverts commit a4e07d4. In preparation for the next commit.

Fix test_wrap_malloc_mimalloc

23f8935

Update ChangeLog.md

0158c62

Fix wasm64_4gb.test_wrap_malloc_mimalloc

9607089

Revise commit 23f8935 and 9607089

094d31e

Resolves: emscripten-core#23090.

kleisauke mentioned this pull request Apr 16, 2026

test_wrap_malloc currently failed under mimalloc #23090

Open

sbc100 reviewed Apr 16, 2026

View reviewed changes

kleisauke added 2 commits April 16, 2026 18:39

Merge branch 'main' into mimalloc-update-3.3.0

4207b4f

Add TODO comment

dcf3cfd

	// Minimal alignment necessary. On most platforms 16 bytes are needed
	// due to SSE registers for example. This must be at least `sizeof(void*)`
	#ifndef MI_MAX_ALIGN_SIZE
	#define MI_MAX_ALIGN_SIZE 16 // sizeof(max_align_t)
	#endif

	// Configuration: specifies the minimum alignment that malloc()ed memory outputs. Allocation requests with smaller alignment
	// than this will yield an allocation with this much alignment.
	#define MALLOC_ALIGNMENT alignof(max_align_t)
	static_assert(alignof(max_align_t) == 8, "max_align_t must be correct");

	#if (MI_MAX_ALIGN_SIZE > 4*MI_INTPTR_SIZE)
	#error "define alignment for more than 4x word size for this platform"
	#elif (MI_MAX_ALIGN_SIZE > 2*MI_INTPTR_SIZE)
	#define MI_ALIGN4W // 4 machine words minimal alignment
	#elif (MI_MAX_ALIGN_SIZE > MI_INTPTR_SIZE)
	#define MI_ALIGN2W // 2 machine words minimal alignment
	#else
	// ok, default alignment is 1 word
	#endif

	if (!_mi_os_has_virtual_reserve()) {
	arena_reserve = arena_reserve/4; // be conservative if virtual reserve is not supported (for WASM for example)
	}

	// Do we have __builtin_thread_pointer? This would be the preferred way to get a unique thread id
	// but unfortunately, it seems we cannot test for this reliably at this time (see issue #883)
	// Nevertheless, it seems needed on older graviton platforms (see issue #851).
	// For now, we only enable this for specific platforms.
	#if !defined(__APPLE__) /* on apple (M1) the wrong register is read (tpidr_el0 instead of tpidrro_el0) so fall back to TLS slot assembly (<https://github.com/microsoft/mimalloc/issues/343#issuecomment-763272369>)*/ \
	&& !defined(__CYGWIN__) \
	&& !defined(MI_LIBC_MUSL) \
	&& (!defined(__clang_major__) \|\| __clang_major__ >= 14) /* older clang versions emit bad code; fall back to using the TLS slot (<https://lore.kernel.org/linux-arm-kernel/202110280952.352F66D8@keescook/T/>) */
	#if (defined(__GNUC__) && (__GNUC__ >= 7) && defined(__aarch64__)) /* aarch64 for older gcc versions (issue #851) */ \
	\|\| (defined(__GNUC__) && (__GNUC__ >= 11) && defined(__x86_64__)) \
	\|\| (defined(__clang_major__) && (__clang_major__ >= 14) && (defined(__aarch64__) \|\| defined(__x86_64__)))
	#define MI_USE_BUILTIN_THREAD_POINTER 1
	#endif
	#endif

Conversation

kleisauke commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kleisauke commented Apr 16, 2026 •

edited

Loading