Repository navigation
docs(wiki): the mimalloc exposure window is a fact about partners, not the edge of the fault - #449
Merged
Merged
Conversation
…e of the fault microsoft/mimalloc#1327 is closed, and reading it changes how the page should be used. The mechanism is macOS-specific — v3 defaulted to fixed TLS slots 108/109, which Apple reserves for the Swift runtime, so co-resident v3 instances shared those cells regardless of symbol visibility. Either side moving off the slot clears it, which is why a fixed pyarrow was sufficient on its own. That makes "pyarrow 24.0.0-25.0.0" a statement about which partners happened to be fixed when, not the boundary of the fault: Arrow bundles v3 across its releases, so pyarrow is one instance of a class. mimalloc 3.4.4 closes it upstream by defaulting macOS to pthreads TLS; libmimalloc-sys has not vendored that, so v3 from Rust today is still the faulting build. Trigger and re-test procedure in #448. Also records what has NOT been measured. The CPython-vendored-mimalloc partner that this page and the Cargo.toml comment both invoke is unmeasured: the 3.14 arm was GIL-enabled, where CPython's mimalloc is not the active allocator. Said so rather than leaving the claim standing on a run that could not have tested it.
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.
✅ Based on
main— no stacking, safe to merge when CI is green.Follows #447. That PR recorded the fault's second face; this one corrects how the page's version window should be read, after reading the upstream issue properly.
What changed in my understanding
microsoft/mimalloc#1327 is closed as completed, and the mechanism in it is narrower than "two mimallocs in one process": on macOS, v3 defaulted to fixed TLS slots 108/109, which Apple's libpthread reserves for the Swift runtime, so co-resident v3 instances shared those two cells regardless of symbol visibility. Either side moving off the fixed slot clears the collision — which is exactly why a fixed pyarrow was sufficient on its own in #447's matrix, with an unfixed allocator on our side.
mimalloc 3.4.4 defaults macOS to pthreads TLS and closes it.
libmimalloc-syshas not vendored that — its newest release predates 3.4.4 and still ships v3 = 3.3.2 with the Apple fixed-slot path — so v3 from Rust today remains the faulting build. Trigger and re-test procedure are in #448; the pin stays until then.Why the page needed the edit
It framed the exposure as "pyarrow 24.0.0–25.0.0". That is true, but it reads as the boundary of the fault when it is really a statement about which partners happened to be fixed when. Arrow bundles v3 across its releases (23.0.0 → 3.1.5, 24.0.0 → 3.2.7, main → 3.3.1), so pyarrow is one instance of a class, and anyone reading the window as the danger zone will under-estimate a future partner.
And what is NOT measured
The page and
rust-packages/laterite-py/Cargo.tomlboth invoke CPython 3.14's vendored mimalloc as a second co-residency partner "regardless of pyarrow". I tried to measure it and did not: the 3.14 arm was a GIL-enabled build, where CPython's vendored mimalloc is not the active allocator. It came back clean, and that result cannot support the claim. Closing it needs a free-threaded3.14tbuild, which is listed in #448.Recorded as unmeasured on the page rather than left standing on a run that could not have tested it.
Wiki gates run clean:
reindex.py --check,lint.py --since origin/main(LINT CLEAN),check_doc_refs --check.