Dropping nedmalloc support? was Re: [PATCH 3/6] mingw: do not use nedmalloc on Windows/ARM64

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 22, 2025, 08:17 UTC
Message-ID: <00fd3145-b3d2-ddab-466d-d06fd27298ec@gmx.de>
In-Reply-To: <aAdIlq8Np8LpahLS@pks.im>

Hi Patrick,

On Tue, 22 Apr 2025, Patrick Steinhardt wrote:

Show 10 quoted lines

> On Mon, Apr 21, 2025 at 12:39:07PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > It does not compile there, and seeing as nedmalloc has been pretty much
> > unmaintained since at least November 2017, as per
> > https://github.com/ned14/nedmalloc/issues/20#issuecomment-343432314,
> > there is also no hope that any fixes will materialize there.
> 
> This kind of raises the question whether we want to keep on maintaining
> nedmalloc in our codebase at all. Is there any strong reason to have it?

To the contrary, There is a very strong reason to drop it: nedmalloc is unmaintained.

There is just a teeny tiny blocker before it can be dropped, though:

$ git grep -n USE_NED_ALLOCATOR upstream/master -- ':(exclude)Makefile' upstream/master:config.mak.uname:478: # USE_NED_ALLOCATOR = YesPlease upstream/master:config.mak.uname:741: USE_NED_ALLOCATOR = YesPlease upstream/master:contrib/buildsystems/CMakeLists.txt:258: USE_NED_ALLOCATOR OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP

The commented-out one is the MSVC build (I had experimental Git for Windows patches to enable nedmalloc even in MSVC builds, which I abandoned in favor of https://github.com/git-for-windows/git/pull/4580 to enable mimalloc in MSVC builds, but I abandoned that effort, too, because Git decided to favor Meson over first-class MSVC support and I decided to focus on avoiding to have my time wasted by the Git project).

As you are quite aware (because it caused plenty of trouble with your reftable patch series), Git for Windows switched to mimalloc quite a while ago (https://github.com/microsoft/mimalloc).

When I switched Git for Windows to mimalloc, I did (re-)run a couple of performance tests to see whether having a custom allocator is still necessary, and from my (unfortunately too vague) recollection, Windows 11's default allocator seems to have performed quite well in comparison. Which is in stark contrast to the results of the performance tests I ran when originally integrating nedmalloc. So: In theory, Git for Windows could drop building with a custom allocator, iff it wasn't for older Windows version that are still supported.

Which means that I would like to upstream the vendored-in mimalloc first, with the patch to use it when building on Windows by default, before dropping nedmalloc from Git's source code.

Ciao, Johannes