Skip to content

chore: remove outdated var usages - #1364

Merged
Electroid merged 2 commits into
mainfrom
sno2-patch-1
Oct 21, 2022
Merged

Electroid merged 2 commits into
mainfrom
sno2-patch-1

Conversation

@sno2

@sno2 sno2 commented Oct 21, 2022

Copy link
Copy Markdown
Contributor

No description provided.

@github-actions github-actions Bot added the chore Task to improve the repository label Oct 21, 2022

@Electroid Electroid left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@Electroid
Electroid merged commit 6160dc3 into main Oct 21, 2022
@Electroid
Electroid deleted the sno2-patch-1 branch October 21, 2022 16:54
Jarred-Sumner added a commit that referenced this pull request Aug 24, 2026
) (#40138)

### What does this PR do?

Bumps mimalloc to oven-sh/mimalloc#27, which combines
oven-sh/mimalloc#22–#26 and replaces their per-reader fixes with one
teardown protocol for `mi_heap_delete` / `mi_heap_destroy`.

The problem those PRs were circling: a heap is torn down while a
concurrent cross-thread `mi_free`, or a thread that used the heap
earlier and still caches a theap for it, can reach it. The hole in the
middle was that the deleter claimed pages by *writing* to them
(`atomic_or` of the owned bit) with nothing pinning the page, so a
concurrent free could release the page and the slice be reused in
between. Now: detach theaps → abandon their pages as thread-exit does →
pin-then-claim every abandoned page (the same bitmap-as-pin protocol the
abandoned-page map already uses) → free theaps → free heap. Details,
contract and tests in the mimalloc PR.

Also in the bump: mimalloc#22 (THP opt-out only when the system setting
is `always` — saves a `madvise` per mmap on Debian/Ubuntu defaults),
from mimalloc#23 only the scavenger signal mask (a fault on that thread
produced no crash report), the scavenger thread starting lazily (a
single-threaded `bun -e` no longer spawns it: −1 thread, −24 syscalls),
and targeted upstream dev3 fixes (thread-locals-after-free guard, #1364,
#1371, NUMA node count). Upstream's in-progress page-meta layout rework
is deliberately *not* included.

**What this does not do:** fix the Windows corrupted-free-list crash
family (BUN-40BH and siblings). Those lists are written by Bun — #39897
(file read completing into a freed buffer, merged) and #39643 (poll
handle freed twice from a nested event loop, open) — and mimalloc is
only where the damage surfaces. #23's "validate links and cut the list"
is not taken for that reason: it would keep running past the write and
hide it.

### How did you verify your code works?

- mimalloc `ctest`: Release 23/23, Debug (`MI_DEBUG_FULL`) 24/24 (was
20/21 on the old pin), ASAN 22/22, TSAN 19/19 with 0 reports (see
mimalloc#27).
- `bun bd test`: transpiler (190/190), bundler_edgecase (138/138),
bundler_minify (43/43), css (2358 pass; 6 debug-timeout fuzz tests),
workers/serve (same 4 failures as a `main` debug build on this box).
- Release x64, n=7 interleaved, old pin vs new pin on the same Bun
commit:

| | old pin median (range) | new pin median (range) | Δ |
|---|---|---|---|
| `bun -e 1` peak RSS | 27024 KB (26564–27088) | 26016 KB (25984–26020)¹
| −3.7% |
| `bun -e 1` syscalls | 270 | 246 | −24 (no `clone3` for the scavenger,
−6 `rt_sigprocmask`, −5 `madvise`) |
| `Bun.serve` hello RSS after 200k req (c=64) | 49760 KB (48540–50040) |
47948 KB (46384–48252) | −3.6% |
| `bun build --minify --sourcemap` three.js×10 peak | 345696 KB
(340672–348928) | 343724 KB (339612–348828) | −0.6% (overlaps) |

¹ one run at 17212 KB excluded from the range as an outlier. The first
two rows come from the scavenger thread now starting on first use (first
park / first scheduled purge) instead of at process init — a change made
because the eager start aborted macOS processes that `DYLD_INSERT` the
dylib (thread created before libobjc initializes); `bun -e 1` never
needs it. Before that change the same A/B was flat (+0.1–0.3%,
overlapping), so the teardown protocol itself is RSS-neutral as
forecast.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chore Task to improve the repository

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants