Mimalloc with vcpkg on Windows

[F-I-D-O]

Hi, I was able to integrate mimalloc into my project, with great results: before the parallel execution was negated by the allocation, now with mimalloc, the speedup is almost linear.

However, I spent quite some time with the integration. Compared with other libraries, which I integrated by just installing them to vcpkg, the mimalloc did not work that way. There is a package mimalloc on vcpkg, but it obviously does not work as expected, even with the override component. In the end, I just gave up and build mimalloc manually using the solution in the mimalloc project, linked it from CMake with an absolute path, and manually copied the dll to my project.

I just wonder, is there some principal problem with the vcpkg/CMake integration on Windows or can I fix it with just a little effort?

[RT2Code]

Hello,

The vcpkg mimalloc port uses CMake to build on every platform. This leads to some issues on Windows like dynamic overriding being unavailable because it requires to build mimalloc from the VS solution to get the necessary dlls files. I also have crashes in debug mode on Windows when I include "mimalloc-new-delete.h" which disappears if I use the libraries built from the mimalloc VS solutions instead. I suppose that's why the documentation recommend to use the VS solution to build mimalloc for Windows, and CMake to build on every other platform.

[Edit] : After more tests and having studied mimalloc more extensively, I now understand that I had got this part wrong and that there's no problem about using CMake to build mimalloc on Windows. But the question still stands : Is there any advantage on Windows to build mimalloc from the VS solution? It's important because using only CMake to build mimalloc allows to keep things as simple as possible in the vcpkg port.

@daanx I'm working on an improvement of the current vcpkg port to fix some issues and add features, but first I need to be sure I understand perfectly how to build and use mimalloc. I carefully read the documentation and many issues, and I made a list to summarize the different ways to build and use mimalloc. Can you review it to check there's no mistakes and to answer some questions I still have?

Direct API use

• Build with the MI_BUILD_STATIC or MI_BUILD_SHARED option enabled.
• Link with the static or dynamic library.
• Include mimalloc.h.

Static override with mimalloc-override.h (all platforms)

• Only reliable if all sources are under the user control.
• Build with the MI_BUILD_STATIC option enabled.
• The MI_OVERRIDE option should not be enabled.
• Link with the static library.
• Include mimalloc-override.h in every source file.
• mimalloc-new-delete.h should not be included.
• Has issues on Windows : https://github.com/microsoft/mimalloc/issues/453
• Is this override method also possible with the dynamic lib :question:

Static linking override (Unix systems only)

• Build with the MI_BUILD_OBJECT and MI_OVERRIDE options enabled.
• Link with the single object file (mimalloc-override.o).
• mimalloc-new-delete.h should not be included.
• mimalloc-override.h should not be included.

Dynamic override (recommended)

• Build with the MI_BUILD_SHARED and MI_OVERRIDE options enabled.
• mimalloc-override.h should not be included.
• On Windows :
  • Requires to link with the dynamic CRT library.
  • Link with the override DLL and set mimalloc-redirect.dll in the same folder.
  • mimalloc-new-delete.h should be included (in a single source file).
  • Does mimalloc-redirect.lib serves any purpose :question:
• On Unix :
  • Preload the shared library : env LD_PRELOAD=/usr/lib/libmimalloc.so myprogram
  • mimalloc-new-delete.h should not be included.
• On MacOS :
  • Preload the shared library : env DYLD_INSERT_LIBRARIES=/usr/lib/libmimalloc.dylib myprogram
  • mimalloc-new-delete.h should not be included.

Extra Features

• Secure : Build with the MI_SECURE option enabled.
• Asm : Build with the MI_SEE_ASM option enabled.

Visual Studio Solution

• Does building mimalloc from the VS solution provides any advantage over CMake on Windows :question:
• Is it possible to generate the assembly files from the VS solution :question:

[bencherian]

@RT222 One issue I've found with the vcpkg mimalloc install is that because it builds everything as C++, it ends up using RtlGenRandom instead of BCryptGenRandom and causes occasional crashes in some versions of Windows as described in #623.

[RT2Code]

Which compiler are you using? Because even if the vcpkg port is indeed enforcing C++ everywhere (which is not ideal and should be fixed), mimalloc is by default configured to build with C++ on MSVC or the Intel compiler, so this should not be an issue on these.

[bencherian]

I'm using VS2019 with vcpkg. I guess this is a generic issue with CMake builds on Windows then. I don't think the VS solutions force C++ use. This is the offending line of code that enables use of RtlGenRandom instead of BCrypt when C++ is enabled.

[RT2Code]

I checked it and I found that the VS solutions are also configured to build with C++ :

According to the comments in the file you mentioned, the use of RtlGenRandom is supposed to fix some issues with BCryptGenRandom, except on Windows Server 2019 where BCryptGenRandom is needed apparently. Are you using mimalloc on Windows Server 2019?

[bencherian]

Sorry, I should have been clearer. I'm using the mimalloc-override solution from VS which is set to "compile as default". I have a crash in certain versions of Win10 which is associated with this function. Based on that issue, it seems like using BCrypt is the "right" thing to do.

[daanx]

Hi -- improving vcpkg support would be great!

Some quick thoughts:

• in the latest dev,dev-slice the BCrypt api is always used now unless cmake is configured with MI_USE_RTL_GENRANDOM so that should remove the difference between C and C++ compilation.
• I think I use C++ compilation on Windows so the std::get_new_handler can be used to properly implement C++ semantics for new. (on unix I can use weak symbol to do this also in C). Also, msvc is a proper C++ compiler but full C compliance is not quite there -- so on MSVC with C compilation the atomics are implemented awkwardly (but it works).

I'll follow up later with your other design document

[skh1000]

@daanx or someone -- can someone do what's necessary to get vcpkg to have a (newest) version of mimalloc that works well on Windows Server 2019? I.e. that uses BcryptRandom instead of the Rtl version? I think it would be good if it works out of the box, with an appropriate vcpkg (manifest) version. Maybe have two flavors for each code version, or something.

[skh1000]

Some suggestions: either a “feature” in the vcpkg manifest, or maybe even an environment variable that would switch what is used at runtime. You would then set this appropriately for windows server 2019, or any other windows os where it’s s problem.