mingw: stop using nedmalloc#2104
Open
dscho wants to merge 6 commits intogitgitgadget:masterfrom
Open
Conversation
Member
Author
|
/submit |
|
Submitted as pull.2104.git.1777811392756.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
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 |
|
User |
dscho
force-pushed
the
stop-using-nedmalloc-with-mingw
branch
2 times, most recently
from
f2ac269 to
0875eff
Compare
The vendored nedmalloc allocator under compat/nedmalloc/ has been unmaintained upstream for a very long time: the original repository at https://github.com/ned14/nedmalloc received its last commit on July 5, 2014, and was archived (made read-only) by its owner on March 15, 2019. Our copy has been carried forward unchanged ever since. The Git for Windows commit that introduced mimalloc as a replacement on Windows ("mingw: use mimalloc", 2019-06-24, present in the Git for Windows branch thicket but not upstream) already observed at that time that nedmalloc had ceased to see any updates for several years. This came to a head when the Git for Windows SDK upgraded to GCC 16: the `add_segment()` function in `compat/nedmalloc/malloc.c.h` declares `int nfences = 0` and only references it inside an `assert()`, which GCC 16 now flags as `-Wunused-but-set-variable`. Combined with the `-Werror` enabled by `DEVELOPER=1`, this turns into a hard build failure: compat/nedmalloc/malloc.c.h: In function 'add_segment': compat/nedmalloc/malloc.c.h:3897:7: error: variable 'nfences' set but not used [-Werror=unused-but-set-variable=] 3897 | int nfences = 0; | ^~~~~~~ cc1.exe: all warnings being treated as errors The same source built without complaint under GCC 15.2.0; the regression was bisected to the SDK package update at git-for-windows/git-sdk-64@188d93dd455 (`mingw-w64-x86_64-gcc 15.2.0-14 -> 16.1.0-1`), with the failing CI run captured at https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074. Rather than patch the unmaintained vendored sources to silence the warning, stop opting into nedmalloc altogether on Windows. 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 completes successfully. The compat/nedmalloc/ subtree itself is removed by subsequent commits in this series. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the previous commit removing every opt-in, the build-system plumbing for nedmalloc has nothing left to switch on. Remove it so that the upcoming deletion of the compat/nedmalloc/ tree is a pure file removal. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
stop-using-nedmalloc-with-mingw
branch
from
0875eff to
90d4137
Compare
Member
Author
|
/submit |
|
Submitted as pull.2104.v2.git.1778169613.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
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. |
The previous two commits stopped opting into nedmalloc on Windows
and stripped out the build-system plumbing that referenced it; the
compat/nedmalloc/ subtree now has no callers and no consumers in
the build, so retire it from the tree.
Logically this is a single deletion of compat/nedmalloc/ in its
entirety: License.txt, Readme.txt, nedmalloc.{c,h}, and the bulk of
the subtree, malloc.c.h. Unfortunately malloc.c.h alone is roughly
196 KB while the Git mailing list rejects messages over 100 KB, so
the deletion is artificially split across four commits cut at file
or section-banner boundaries: this commit (the smaller auxiliary
files) plus three chunks of malloc.c.h cut at its own top-level
section banners ("Overlaid data structures" and "System
allocation"). The split is purely a mailing-list accommodation,
not a logical separation; the three follow-up patches in this
series carry "to be squashed into 3/6" subjects so they can be
folded back into this commit at integration time, per Junio's
suggestion in
<https://lore.kernel.org/git/xmqqfr42fw30.fsf@gitster.g/>.
Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
stop-using-nedmalloc-with-mingw
branch
from
90d4137 to
6e0fd51
Compare
Member
Author
|
/submit |
|
Submitted as pull.2104.v3.git.1778244661.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
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 |
|
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 |
|
User |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
MINGWbuilds 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.halone 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:
Changes since v1:
cc: Patrick Steinhardt ps@pks.im
cc: Jeff King peff@peff.net