mingw: stop using nedmalloc

[dscho]

Git for Windows' SDK wants to update GCC to v16. Since it is used in the CI builds also of the git/git repository, it is crucial that GCC can compile even the latter all right, but currently it does not, see https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074.

Git for Windows switched away from nedmalloc to mimalloc a long time ago, but recent benchmarks across Windows, macOS, and Linux (see git-for-windows#6231) show no measurable benefit from mimalloc over the platforms' default allocators, so rather than upstreaming the mimalloc support, I will drop it from Git for Windows entirely.

This series therefore disables nedmalloc for MINGW builds and removes the vendored-in nedmalloc from Git's source code; my earlier sketch in https://lore.kernel.org/git/00fd3145-b3d2-ddab-466d-d06fd27298ec@gmx.de/ had the opposite ordering only because it assumed mimalloc would land first. Since that's not going to happen, it's best to move forward with this, so that the CI builds can switch to using GCC 16 (and the current Git for Windows SDK) on Windows.

The patches that remove the vendored sources have a slightly unusual shape: the Git mailing list rejects messages over 100kB and compat/nedmalloc/malloc.c.h alone is ~196kB of source, so the deletion of that file is split at section boundaries into three commits, each comfortably under the cap. The intention (as documented by the last three commit messages) is for them to be squashed by the Git maintainer before merging.

Changes since v2:

• Reworded the last 4 patches as recommended by Junio, in preparation for squashing them on his end.

Changes since v1:

• Also remove nedmalloc from the CMake and Meson configurations in the first patch.
• Add follow-up patches that drop the nedmalloc build-system plumbing and source files.

cc: Patrick Steinhardt ps@pks.im
cc: Jeff King peff@peff.net

[dscho]

/submit

[gitgitgadget]

Submitted as pull.2104.git.1777811392756.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2104/dscho/stop-using-nedmalloc-with-mingw-v1

To fetch this version to local tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v1

[gitgitgadget]

Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):

On Sun, May 03, 2026 at 12:29:52PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Rather than patch the unmaintained vendored sources to silence the
> warning, stop opting into nedmalloc altogether on MINGW. The platform
> allocator is what every non-MINGW build already uses, and a fresh
> build of git.git's master against a minimal Git for Windows SDK
> upgraded to GCC 16, with `USE_NED_ALLOCATOR` removed from the MINGW
> section, completes successfully.
> 
> The compat/nedmalloc/ subtree itself is left in place to keep this
> change minimal; nothing in the build links against it any longer, so
> it can be removed in a follow-up if desired.

I guess this is fair as an intermediate step. But seeing that this
removes the last user per our "config.mak.uname" I do wonder whether we
want to maybe drop nedmalloc completely. Not necessarily in this patch,
but maybe in a subsequent step?

Thanks!

Patrick

[gitgitgadget]

User Patrick Steinhardt <ps@pks.im> has been added to the cc: list.

[dscho]

/submit

[gitgitgadget]

Submitted as pull.2104.v2.git.1778169613.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2104/dscho/stop-using-nedmalloc-with-mingw-v2

To fetch this version to local tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v2:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v2

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> The patches that remove the vendored sources have a slightly unusual shape:
> the Git mailing list rejects messages over 100kB and
> compat/nedmalloc/malloc.c.h alone is ~196kB of source, so the deletion of
> that file is split at section boundaries into three commits, each
> comfortably under the cap.

The history made strange only by the limitation of the tool (i.e.,
mailing list) we use is like the tail wagging the dog.  Could you
give a commit log message that describes droppage of everything done
in the "artificially stepwise only due to mailing list limitation,
but we wish we could do in a single step because the separation is
not logical at all" in the later steps, to the first of such steps
([2/6], I presume), and give each remaining patch a single liner "to
be squashed into [2/6]" log message, or something?  Then I can
squash them on my end.  Alternatively for this one only after we get
favourable reviews on the early two steps to drop the use of the
library, I can pull a single "discard everything" patch that builds
on these two from your repository.

Thanks.

[dscho]

/submit

[gitgitgadget]

Submitted as pull.2104.v3.git.1778244661.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2104/dscho/stop-using-nedmalloc-with-mingw-v3

To fetch this version to local tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v3:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2104/dscho/stop-using-nedmalloc-with-mingw-v3

[gitgitgadget]

Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):

On Fri, May 08, 2026 at 12:50:55PM +0000, Johannes Schindelin via GitGitGadget wrote:
> Git for Windows' SDK wants to update GCC to v16. Since it is used in the CI
> builds also of the git/git repository, it is crucial that GCC can compile
> even the latter all right, but currently it does not, see
> https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074.
> 
> Git for Windows switched away from nedmalloc to mimalloc a long time ago,
> but recent benchmarks across Windows, macOS, and Linux (see
> https://github.com/git-for-windows/git/pull/6231) show no measurable benefit
> from mimalloc over the platforms' default allocators, so rather than
> upstreaming the mimalloc support, I will drop it from Git for Windows
> entirely.
> 
> This series therefore disables nedmalloc for MINGW builds and removes the
> vendored-in nedmalloc from Git's source code; my earlier sketch in
> https://lore.kernel.org/git/00fd3145-b3d2-ddab-466d-d06fd27298ec@gmx.de/ had
> the opposite ordering only because it assumed mimalloc would land first.
> Since that's not going to happen, it's best to move forward with this, so
> that the CI builds can switch to using GCC 16 (and the current Git for
> Windows SDK) on Windows.
> 
> The patches that remove the vendored sources have a slightly unusual shape:
> the Git mailing list rejects messages over 100kB and
> compat/nedmalloc/malloc.c.h alone is ~196kB of source, so the deletion of
> that file is split at section boundaries into three commits, each
> comfortably under the cap. The intention (as documented by the last three
> commit messages) is for them to be squashed by the Git maintainer before
> merging.
> 
> Changes since v2:
> 
>  * Reworded the last 4 patches as recommended by Junio, in preparation for
>    squashing them on his end.

Heh, fun.

> Changes since v1:
> 
>  * Also remove nedmalloc from the CMake and Meson configurations in the
>    first patch.
>  * Add follow-up patches that drop the nedmalloc build-system plumbing and
>    source files.

I think removing nedmalloc makes sense, and am happy with the state of
this series. Thanks!

Patrick

[gitgitgadget]

Jeff King wrote on the Git mailing list (how to reply to this email):

On Fri, May 08, 2026 at 11:56:19AM +0900, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > The patches that remove the vendored sources have a slightly unusual shape:
> > the Git mailing list rejects messages over 100kB and
> > compat/nedmalloc/malloc.c.h alone is ~196kB of source, so the deletion of
> > that file is split at section boundaries into three commits, each
> > comfortably under the cap.
> 
> The history made strange only by the limitation of the tool (i.e.,
> mailing list) we use is like the tail wagging the dog.  Could you
> give a commit log message that describes droppage of everything done
> in the "artificially stepwise only due to mailing list limitation,
> but we wish we could do in a single step because the separation is
> not logical at all" in the later steps, to the first of such steps
> ([2/6], I presume), and give each remaining patch a single liner "to
> be squashed into [2/6]" log message, or something?  Then I can
> squash them on my end.  Alternatively for this one only after we get
> favourable reviews on the early two steps to drop the use of the
> library, I can pull a single "discard everything" patch that builds
> on these two from your repository.

Could this be a good time to use --irreversible-delete? It is not like
humans are going to read the 200k of deletion hunks anyway.

-Peff

[gitgitgadget]

User Jeff King <peff@peff.net> has been added to the cc: list.