[Fedr]

BitSet stores its blocks with mimalloc explicitly, and executables that override malloc (mr_enable_mimalloc, also MeshViewer and MRTest, as on master) forward it to the same mimalloc, so every process has exactly one mimalloc heap. The mimalloc comes from the dependencies, built without the malloc override, so MeshLib libraries can be loaded late into any process (Python, .NET, Java).

An alternative to #7236, which fetches and builds its own MRMimalloc instead.

Allocator

• BitSet::Blocks is std::vector<block_type, Allocator<block_type>>. The new MRAllocator.h defines MR::Allocator<T> as mi_stl_allocator<T>.
• It is std::allocator<T> with the new option MRMESH_NO_MIMALLOC, named like the other optional dependencies (MRIOEXTRAS_NO_*, MRVIEWER_NO_*). It defaults to ON in Emscripten builds, where malloc is mimalloc already with MR_EMSCRIPTEN_MIMALLOC, and in macOS Homebrew builds, because Homebrew's mimalloc overrides malloc. It is a public compile definition of MRMesh, so code built against installed MeshLib sees it too, and an entry in config_cmake.h.
• MRMesh links the dependencies' mimalloc PUBLIC through mr_find_mimalloc().
• On MSVC, MRAllocator.h auto-links mimalloc(-debug).dll.lib, so consumers that link only MRMesh by name resolve the inline mi_free.

Dependencies

Build	mimalloc
Ubuntu (thirdparty/cpm/stage1)	3.5.3 shared, MI_OVERRIDE=OFF, local-dynamic TLS, release-built
vcpkg Linux and macOS (stock port, vcpkg 2026.10.16)	3.5.3 shared, no override feature (it is Windows-only in vcpkg.json), release-only like everything in MeshLib's Linux/macOS triplets, local-dynamic TLS from the Linux triplets
vcpkg Windows	stock mimalloc[override], as before (the override feature is now Windows-only in vcpkg.json)
macOS Homebrew	Homebrew's override mimalloc, used only by mr_enable_mimalloc executables, as on master

The libraries never load an override mimalloc, which would crash a plain Python loading it late. Release-only builds matter because the same mimalloc can be the allocator of the whole process (below).

Executables

mr_enable_mimalloc makes malloc use the libraries' mimalloc; it needs no option, as overriding is always safe now:

• Linux: the thin MRMimallocOverride library (source/MRMimallocOverride/MRMimallocOverride.cpp), first in the link order. It defines the Linux list of mimalloc 3.5.3's src/alloc-override.c (malloc & co, glibc's __libc_*) and every operator new/delete as calls to mi_*.
• macOS vcpkg: MRMimallocOverride (MRMimallocOverrideMacOS.cpp), a port of mimalloc's macOS override (alloc-override.c with MI_OSX_INTERPOSE plus src/prim/osx/alloc-override-zone.c) to the public API. It uses dyld __interpose tuples and a mimalloc malloc zone. Two things differ from mimalloc's single-image override:
  • dyld applied only interposes whose replacement is in the interposing image, so each replacement is a local wrapper.
  • The library's own calls are interposed too, so realpath is left out: mi_realpath calls it, which recursed.
• MRMESH_NO_MIMALLOC (macOS Homebrew): the dependencies' mimalloc, Homebrew's override one, as on master (the libraries use std::allocator).
• Windows: the redirect of the same vcpkg mimalloc.dll, unchanged.

MRMimallocOverride is built on macOS and Linux unless MRMESH_NO_MIMALLOC. MeshViewer and MRTest call mr_enable_mimalloc again (MSBuild: MimallocRedirect.props), as on master, so every CI job tests the override.

Packages and bindings

• MRMeshConfig.cmake defines the mimalloc target for code built against installed MeshLib: vcpkg's package on Windows; elsewhere the dependencies' libmimalloc copied with MeshLib (the thirdparty lib dir in the .deb, vcpkg's lib dir in vcpkg installs), with the copied thirdparty include dir.
• bits() and fromBlocks are hidden from the bindings (MR_BIND_IGNORE), because mrbind drops custom allocators (see this C bindings error). generate.mk reads MRMESH_NO_MIMALLOC from MRMesh's config_cmake.h, so the bindings agree with MRMesh on BitSet::Blocks.
• MRCuda builds its result blocks as BitSet::Blocks, and DynamicArray accepts a std::vector with any allocator.

Tests

MRMimallocRedirectTests.cpp:

• MimallocRedirectActive: malloc and new return mimalloc memory. On Windows the redirect is active, and on macOS the default malloc zone is mimalloc's.
• MimallocBitSet: BitSet blocks come from mimalloc, also those allocated inside MRMesh.
• MimallocSharedLibrary (Linux, macOS): exactly one libmimalloc* is loaded, plus libMRMimallocOverride (unless MRMESH_NO_MIMALLOC), and mimalloc.h matches the library's version.

The file is skipped where malloc is not mimalloc (Emscripten without MR_EMSCRIPTEN_MIMALLOC, MRMESH_NO_MIMALLOC outside macOS Homebrew).

Performance

Boolean timing of an overriding executable built with this PR matches master (the dependencies' override mimalloc replacing malloc) on 8 Linux, 3 Windows and 2 macOS CI jobs, interleaved on the same machine (two samples of the Linux and Windows jobs). Measured with #7236's MRMimalloc, the same mimalloc 3.5.3 built the same way, local-dynamic TLS costs nothing measurable.

🤖 Generated with Claude Code

[Grantim]

why override here? does it only takes effect on MeshViewer and TestApp?

[Fedr]

Yes, it only changed MeshLib's own executables (MRTest, MeshViewer), to test the override path in CI. It is gone now: MR_MIMALLOC_OVERRIDE is removed, and MRTest and MeshViewer always override malloc again, as on master, so every CI job tests it.

[Grantim]

is it just client property that we always disable on our side? (mb in this case it is better to use common naming MR_NO_MIMALLOC like we do for other optional thirdparties?)

[Fedr]

It is not a client property: it is ON by default in Emscripten builds (malloc is already mimalloc there) and in macOS Homebrew builds (Homebrew's mimalloc overrides malloc, and its mimalloc.h of any version comes first in the include path). Renamed to the option MRMESH_NO_MIMALLOC with those defaults, like MRIOEXTRAS_NO_* and MRVIEWER_NO_*.

[Grantim]

seems a bit strange to have too different flags: MR_MIMALLOC_OVERRIDE and MR_STD_ALLOCATOR

[Fedr]

Agreed, MR_MIMALLOC_OVERRIDE is removed: an overriding executable now forwards malloc to the libraries' own mimalloc, so overriding is always safe and mr_enable_mimalloc needs no option. MRMESH_NO_MIMALLOC is the only flag left.