gh-113141: Mimallocv3

[DinoV]

• Issue: Mimalloc differences from upstream #113141

[python-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• daanl@outlook.com

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #35281269 | 📁 Comparing a8e2a42 against main (415ebff)

  🔍 Preview build  

18 files changed · ± 18 modified

± Modified

• license.html
• py-modindex.html
• c-api/extension-modules.html
• c-api/file.html
• c-api/import.html
• c-api/interp-lifecycle.html
• c-api/intro.html
• c-api/structures.html
• library/bdb.html
• library/ctypes.html
• and 8 more...

[StanFromIreland]

@daanx can you please sign the CLA?

[daanx]

@daanx can you please sign the CLA?

Ah yes, but not really for the current PR as that includes the full mimalloc v3 vendored sources and that is a separate project under the MIT license.

I can of course sign off for the changes I made on the CPython side. The current PR contains both, maybe we can split it? I think commit cedd47b is the CPython part only, while the other commits are just importing mimalloc v3 as a vendored library.

[daanx]

Using MI_WIN_INIT_USE_FLS is not really encouraged for mimalloc. If we can use the default that would be best.

[DinoV]

Using MI_WIN_INIT_USE_FLS is not really encouraged for mimalloc. If we can use the default that would be best.

There's a crash on the Windows builds w/o it currently (and it seems to show up basically at startup but the freeze programs make it through it). I was planning on digging into it more later but this is what Claude came up as a fix - I just don't have immediate access to a Windows machine to see where the actual crash is coming from. But that's why it's there for now.

Right now I'm just trying to get things to green CI and then I'll clean up the final result.

[DinoV]

@corona10 Hey here it is!

[corona10]

For TSAN fail see: 2599016

IIRC, it was already happened at

cpython/Objects/mimalloc/os.c

Lines 245 to 268 in 34fe59b

	else {
	// if not aligned, free it, overallocate, and unmap around it
	// NOTE(sgross): this warning causes issues in Python tests
	// _mi_warning_message("unable to allocate aligned OS memory directly, fall back to over-allocation (size: 0x%zx bytes, address: %p, alignment: 0x%zx, commit: %d)\n", size, p, alignment, commit);
	mi_os_prim_free(p, size, commit, stats);
	if (size >= (SIZE_MAX - alignment)) return NULL; // overflow
	const size_t over_size = size + alignment;
	if (mi_os_mem_config.must_free_whole) { // win32 virtualAlloc cannot free parts of an allocate block
	// over-allocate uncommitted (virtual) memory
	p = mi_os_prim_alloc(over_size, 1 /*alignment*/, false /* commit? */, false /* allow_large */, is_large, is_zero, stats);
	if (p == NULL) return NULL;
	// set p to the aligned part in the full region
	// note: this is dangerous on Windows as VirtualFree needs the actual base pointer
	// this is handled though by having the `base` field in the memid's
	*base = p; // remember the base
	p = mi_align_up_ptr(p, alignment);
	// explicitly commit only the aligned part
	if (commit) {
	_mi_os_commit(p, size, NULL, stats);
	}
	}

[corona10]

About guardrail for memory pressure

any changes expected to increase memory above 15% (with a hard limit of 20%) should be discussed with the SC in advance.

[DinoV]

Perf run is here waiting for results: https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39346123598

[DinoV]

@daanx can you please sign the CLA?

Ah yes, but not really for the current PR as that includes the full mimalloc v3 vendored sources and that is a separate project under the MIT license.

I can of course sign off for the changes I made on the CPython side. The current PR contains both, maybe we can split it? I think commit cedd47b is the CPython part only, while the other commits are just importing mimalloc v3 as a vendored library.

FWIW the docs due already call out mimalloc license: https://docs.python.org/3/license.html#mimalloc although we should probably update the date range w/ the v3 update.

[corona10]

perf run is here waiting for results: https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39346123598

2x to 1.14x but still higher than mimalloc v2

[corona10]

Suggested change

	// Hooks can run under allocator locks, so only consult cached progress.
	if (qsbr != NULL) {
	// Scan thread sequences like the v2 integration did.
	return !_Py_qsbr_poll(qsbr, page->goal);
	}
	// Hooks can run under allocator locks, so only consult cached progress.

[corona10]

Similar logic with

cpython/Objects/obmalloc.c

Line 249 in 4c73f50

if (!_Py_qsbr_poll(tstate->qsbr, page->qsbr_goal)) {

[DinoV]

New benchmark run: https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39373144391

[DinoV]

New benchmark run: https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39373144391

That was still a 6% regression on memory (but things are headed in the right direction, THP tweak about it from 2x to 1.15, and then the _Py_qsbr_poll fix got us here), here's another run https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39476892845 which has commit 3c8be4f that sets mi_option_purge_delay and mi_option_arena_purge_mult to their v2 values.

[DinoV]

Down to a 4% regression now: https://github.com/facebookexperimental/free-threading-benchmarking/tree/main/results/bm-20261020-3.16.0a1+dev-3c8be4f-NOGIL

[DinoV]

Another run with new options for mi_option_arena_purge_min_size, and mi_option_page_full_retain and a tweaked mi_option_arena_purge_mult: https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39497633255