[HN Gopher] I was surprised by how simple an allocator is
___________________________________________________________________
I was surprised by how simple an allocator is
Author : gilgamesh3
Score : 67 points
Date : 2025-06-19 06:20 UTC (3 days ago)
(HTM) web link (tgmatos.github.io)
(TXT) w3m dump (tgmatos.github.io)
| wavemode wrote:
| On first seeing this I wasn't sure what analogy the author was
| trying to make. After reading the article my best guess is that
| they are simply trying to say that, writing an allocator is
| easier than it seems on the surface.
|
| Though it's not clear to me that the article does a good job of
| establishing that this is actually true ("mimalloc is only a few
| thousand lines of code" doesn't pass the smell test).
| majormajor wrote:
| Yeah, re: the title, the URL/path string "allocators-are-for-
| monkeys-with-typewriters" (including on the page) seems more
| clear about that "less hard than you'd think" thing than the
| larger-font published headline "Allocators are Monkeys With
| Typewriters". And of course the quote in the article is even
| more specific "given enough time, even a monkey with a
| typewriter can write a memory allocator".
|
| I generally agree with the "memory management doesn't have to
| be as complicated as you might think" vibe, especially if
| you've read about some optimizations in fancy modern GCs and
| aren't aware of what a basic simple non-GC world can look like.
| That said, of course, you can indeed get into a lot of
| complexity beyond the textbook 101 examples. Like the mentioned
| threading...
| dang wrote:
| We replaced the title with a more representative sentence
| from the article body.
| b0a04gl wrote:
| but saying they're useless ignores a bunch of real systems that
| wouldn't run without them.
|
| in unity, you literally can't do burst compiled jobs efficiently
| unless you choose the right allocator. they expose `Temp`,
| `Persistent`, etc because GC isn't even an option when you're
| fighting for milliseconds per frame. no allocator choice = frame
| skips = shipped bugs.
|
| in embedded, FreeRTOS gives you multiple heap implementations for
| a reason. sometimes you need fixed size pools, sometimes you care
| about fragmentation. malloc's out of the question. same in any
| real time firmware, safety critical or not.
|
| infra world has been using arena allocators for years. folly's
| `Arena`, grpc's arena, even jemalloc has thread caching and slab
| style region reuse built in. this isn't academic. large scale
| systems hit allocation pressure that general purpose allocators
| can't tune for globally.
|
| and rust's whole alloc abstraction : it's more about expressing
| ownership across lifetimes in memory sensitive codebases.
| `Bumpalo` isn't a premature optimization. it's what you reach for
| when you know the object graph layout and want to free it in one
| call. also safe by design. it's not even painful to use.
|
| imo allocator choice is an interface decision. it shapes how the
| rest of your code handles memory lifetimes. once you start
| passing memory lifetimes as part of your type system or job
| model, the whole architecture shifts. this is way deeper than
| faster malloc
| reactordev wrote:
| Allocator choice is a spice, not a staple. There's various
| reasons to use one design vs another for your use case and no
| "one-size fits all". Sometimes you want continuous memory.
| Sometimes you want sorted memory. Sometimes you want fast
| memory damned the internal fragmentation. Others, you want
| terse memory because you're trying to fit a struct in 32 bytes.
| There's a use case for it all.
| jasonthorsness wrote:
| Applications should use more special-purpose memory allocators.
| Much of the complexity in memory management is designing for an
| unknown usage pattern and things can be quite simple when
| allocator is specialized and patterns are predictable.
|
| This is difficult though in higher-level languages. Go tried and
| failed with arenas.
| Snawoot wrote:
| I think I found some solution for arenas in Go:
| https://pkg.go.dev/github.com/Snawoot/freelist
|
| Has some shortcomings, but I think it should work.
| the__alchemist wrote:
| I have an STM32 rust project I've been working on this week. It
| talks to an ESP using protobuf/RPC.
|
| I'm doing it bare-metal/no allocator, as I do most embedded
| projects... and it's flirting with running me out of memory! What
| do most (and the most popular) protobuf libs do in rust? Use an
| allocator. What does the ESP itself do? Use an allocator (with
| FreeRTOS).
|
| Meanwhile I'm using Heapless (Vec and String syntax with a
| statically-allocated array), on a MCU with 128K flash and 32K
| Ram... This won't end well.
| javier2 wrote:
| Think you need an allocator !
| charleslmunger wrote:
| If you use upb, an allocator is optional - you can provide a
| presized block to upb_Arena and a NULL upb_alloc. Of course,
| you'll still fail to parse a message with an in memory
| representation larger than your region.
| dang wrote:
| [stub for offtopicness]
| davydm wrote:
| lol, I read this as "alligators are monkeys with typewriters"
| and thought it would be a well interesting article
|
| but it's just more blah-blah about ai :/
| triknomeister wrote:
| As Andrei Alexandrescu famously said, "Allocator is to
| allocation what alligators is to allegation"
|
| https://www.youtube.com/watch?v=LIb3L4vKZ7U
| bitwize wrote:
| So when people retool their application to use GC do they
| say "See you later, allocator!"?
|
| ...I'll be here all week. Try the veal!
| layer8 wrote:
| It's actually _without_ GC that you have to see the
| allocator again later, to free the memory.
| gilgamesh3 wrote:
| Author of the post here. This talk was one of the talks I
| watched when learning about allocators. I thought about
| writing a part of the post about this talk but I didn't
| have much time.
| freeone3000 wrote:
| I think you might be commenting on the wrong article -- this
| is an implementation of a memory allocator, as in, malloc.
| pmelendez wrote:
| AI? This article is about memory allocation strategies... Did
| I miss something?
| tantalor wrote:
| [flagged]
| keeptrying wrote:
| From the title I thought he meant VCs.
| xeonmc wrote:
| Those would be _alligators_ , rather.
| ekianjo wrote:
| Why change the title? That's also against HN policy
| charcircuit wrote:
| >Seeing that mimalloc does not offer this feature
|
| If you click on the issue you will see that mimalloc already does
| offer this feature via mi_manage_os_memory to create an arena,
| mi_heap_new_in_arena to create a heap that uses the arena, and
| mi_heap_malloc to allocate memory from the heap.
| userbinator wrote:
| Yes, but the article doesn't really show with code why it's
| simple.
|
| A basic first-fit free-list type allocator can be less than 100
| LoC - in x86 Asm. Using free space to store the overhead is a
| simple but effective optimisation too.
___________________________________________________________________
(page generated 2025-06-22 23:00 UTC)