Where did my freed memory (not) go?
Comments on “Where did my freed memory (not) go?”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Yapfast's author found that freeing memory in a Rust app on Linux with glibc barely lowered the kernel's count: heap in use fell from 78 to 55 MiB, but anonymous memory stayed near 97 MiB. The cause was 47 malloc arenas holding free chunks, and freed space in the middle of a heap is not returned. Capping arenas at 2 cut about 8 MiB, and targeted malloc_trim calls recovered more. These figures come from one app, mostly on Linux, and Windows is unmeasured.
Why it ranked
No. 19 of 93 with a score of 0.64. The panel rated it highest on technical depth (0.93) and new information (0.92), lowest on significance (0.45).
Every answer behind this is in the table under Score.
Score
0.64total under rubric v2.2
- Significance0.45
- Reader interest0.76
- Audience breadth0.47
- Practical relevance0.75
- Substantiated0.90
- Technical depth0.93
- New information0.92
- Counts against: Promotional0.04
- Counts against: Overclaim0.17
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| Significance | 0.44 | 0.35 | 0.55 | 0.45 | 0.20 | +0.24 | +0.107 |
| Reader interest | 0.61 | 0.80 | 0.86 | 0.76 | 0.25 | +0.26 | +0.197 |
| Audience breadth | 0.45 | 0.50 | 0.45 | 0.47 | 0.05 | +0.13 | +0.061 |
| Practical relevance | 0.78 | 0.70 | 0.78 | 0.75 | 0.08 | +0.22 | +0.166 |
| Substantiated | 0.97 | 0.85 | 0.88 | 0.90 | 0.12 | +0.05 | +0.045 |
| Technical depth | 1.00 | 0.90 | 0.90 | 0.93 | 0.10 | +0.05 | +0.047 |
| New information | 0.94 | 0.85 | 0.97 | 0.92 | 0.12 | +0.05 | +0.046 |
| Promotional | 0.04 | 0.05 | 0.03 | 0.04 | 0.02 | −0.19 | −0.008 |
| Overclaim | 0.18 | 0.20 | 0.12 | 0.17 | 0.08 | −0.11 | −0.018 |
| Sum of contributions | +0.642 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.642 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-25/19/"><img src="https://rubric.hrih.si/badge/2026-10-25/19.svg" alt="Ranked #19 on Rubric, 25 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 1 matches source · 4 no source given · 3 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Couldn’t checkNumber
glibc creates a separate malloc arena for each thread that allocates, up to eight per CPU core on 64-bit systems, after which threads share arenas.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “it gets an arena of its own, up to eight per CPU core on 64-bit, and past that threads start sharing”
The source says No passage could be compared.
Source cited by the article: man7.org/linux/man-pages/man3/mallopt.3.html
Couldn’t checkNumber
glibc only returns free space at the very top of an arena's heap to the kernel, once it exceeds M_TRIM_THRESHOLD, which defaults to 128 KiB.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “glibc only returns the free space at the very top of that heap, once there's more than M_TRIM_THRESHOLD of it (128 KiB by default”
The source says No passage could be compared.
Source cited by the article: man7.org/linux/man-pages/man3/mallopt.3.html
Matches sourceVersion
Since glibc 2.8, malloc_trim(0) walks every arena and returns any whole free page to the kernel, even in the middle of a heap; before 2.8 it only trimmed the top of the main arena.
The cited source says the same thing.
The article says “since glibc 2.8 (thanks Claude) it walks every arena and tells the kernel it can have back any whole page that's free, even in the middle of a heap”
The source says “Since glibc 2.8 this function frees memory in all arenas and in all chunks with whole free pages”
Source cited by the article: man7.org/linux/man-pages/man3/malloc_trim.3.html
No source givenNumber
With the default glibc settings, Yapfast ended up with 47 arenas, and the gap between held (91.4 MiB) and in-use (78.2 MiB) memory was about 13 MiB.
The article gives no link or citation for it.
The article says “Yapfast runs dozens of threads (Tokio's workers, the audio threads, the call's connections, whatever else), so it ended up with 47 arenas”
The source says No source to compare with.
No source givenCausal conclusion
Capping arenas at 2 with mallopt in main cut the held/in-use gap from 13 MiB to about 1 MiB and lowered the kernel's anonymous memory figure by about 8 MiB, at the same CPU use.
The article gives no link or citation for it.
The article says “The gap between held and in use went from 13 MiB to about 1, and the kernel's number dropped by 8 MiB, at the same CPU”
The source says No source to compare with.
Couldn’t checkNumber
On a fake account with 100 servers and 300 DMs, a server view went from 220–223 MiB of RSS to 170–176 MiB and heap in use from 113 MiB to 75 MiB after the fixes.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “a server view went from 220–223 MiB of RSS6 to 170–176 MiB, and the heap in use from 113 MiB to 75”
The source says No passage could be compared.
Source cited by the article: github.com/yapfast/yapfast/blob/main/testing/fake_discord.ts
No source givenNumber
On the GPU renderer, closing the window to the tray took the kernel's memory figure from 86.6 MiB to 62.9 MiB, while on Skia Software it freed only 2.3 MiB.
The article gives no link or citation for it.
The article says “the first close to the tray took the kernel's number from 86.6 MiB to 62.9, 24 MiB actually back”
The source says No source to compare with.
No source givenCausal conclusion
In the ten person call, the GPU renderer used 78.2 MiB heap in use versus 18.1 MiB for Skia Software, which the author attributes to the graphics driver and Skia's GPU state.
The article gives no link or citation for it.
The article says “The GPU renderer has 60 MiB more heap, all of it the graphics driver and Skia's GPU state”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 3 pts, not on front page
Recorded for context only, checked 25 Oct 2026, 05:46 UTC. It played no part in the ranking.