A
Anonymous12/02/25, 08:30No.107404326Manual Memory Management
Been reading up on MMM lately, and wound up reading Ginger Bill's series on allocators.
So far, in my career, I've seen three patterns for memory management past the C minimum:
1. Leave it to GC
2. Borrow checking (Rust)
3. RAII with tools like smart pointers (C++)
All of these assume that you're going to be slinging arbitrary-sized data onto the heap at more or less random points in program execution and need something to manage those allocations. Ginger Bill alleges this is not true, and that most of the time you really know how much memory you're dealing with. That opens up a new option:
4. Allocator-based management
From what I understand, the principle is to preallocate necessary memory to complete a task, complete it without worrying too much about memory efficiency within the task, and then release all the memory at once.
I expect this would be very efficient for low-level computing like graphics, which Ginger Bill seems to think about a lot. But I'm not convinced that his allocation breakdown makes sense, unless you're counting trivial stack allocations that nobody has trouble managing in the first place. Certainly it doesn't seem to hold in the OOP world of enterprise software, which is what pays the bills for me. Daemons and web servers have constantly shifting allocation sizes according to business need, and most of the garbage I deal with is in his top right corner.
Anyone try programming this way? How did it work in practice?
187
Replies
A
Anon12/02/25, 08:38No.107404367
It's very difficult, but you can do more things.
The guides you are reading sucks.POINTERS - 10 Hours
C is a typeless language, it does not know what data is what type. That is why printf allows you to *interpret* data how you see fit1. Write out each program that is inside the following youtube video
https://www.youtube.com/watch?v=MIL2BK02X8A2. Try to write 1 additional test per program in the video.
Did you learn anything? Did you test it properly?
AND TEST IT.How many additional tests did you write?3. Update your notes of understanding then present those notes to meThis is a course you need to spend 10 hours on to get a medium understanding of pointers, it is very hard learning.
A
Anon12/02/25, 08:41No.107404383
People who say pointers are easy don't know what they're talking about.
A
Anon12/02/25, 08:44No.107404401
isn't that basically making simple programs and then just not calling free when they exit?
A
Anon12/02/25, 08:57No.107404449
No. The analysis is fine of a purely statistical foundation, but nobody cares about the top half of that table.
lifetime/size known is just... a variable. The language handles that for you when you write int i = 0. Nobody needs to think about this. It's the "unknowns" that take most of your memory, and are most prone to causing issues. Of those unknowns, "size known" is often misleading. You very very rarely actually know exactly how much space you will need, if you know the size of one "element" there usually is an unknown number of elements.
"Lifetime known" is also misleading. If the lifetime is short, such as one scope, then it's easy peasy to handle and you don't even think about it. If the upper bound lifetime is measured in real time, or as one "scene", or as part of a complex function, then reserving all that memory until you're ABSOLUTELY sure it can't possibly be needed anymore may be too costly. Imagine a program that recursively reads files keeping each file in memory until the entire process finishes, just to avoid having to manage lifetimes.Overall it sounds like a mathematical approach to memory management that has no bearing on real world applications. Maybe it works for graphics, I don't have much experience in graphics programming, but it's surely not an optimal strategy for most programming
A
Anon12/02/25, 09:25No.107404593
You guys are absolutely wasting your life on this. This is the most premature optimization imaginable. I work as a contractor and I'm brought in to fix shit other people wrote. One round trip to the database dwarfs all your memory allocation concerns for the entire function/method/whatever. I just spent a day dropping a page load from 2000 round trips to the database down to 100. The page is now 10x faster. The client is ecstatic.
At no point in this process did memory allocation make up more than a miniscule fraction of the page load. Not before. Not after. No one cares. Going to the heap is like going to the fridge. Going to the database is going to Jupiter by comparison. You can go to the heap as much as you fucking want and it will never make any goddamn difference at all.
A
Anon12/02/25, 09:45No.107404691
Yes, I do think about code I write and how it works.
A
Anon12/02/25, 09:51No.107404719
instead of splitting hairs about "theory", one can just ask for benchmarks that beat rust used with unhardened (or equivalently hardened) mimalloc/snmalloc/tcmalloc/...
details about when and how "drops" happen aside, borrow-checking and RAII are orthogonal btw (rust has both).
A
Anon12/02/25, 09:54No.107404738
"Computer Science" exists entirely in that last domain, Size Unknown and Lifetime Unknown.
A Turing Machine has no known lifetime (Halting Problem) and requires Infinite Memory.
All those other cases are Finite State Machines.
If you are going to restrict yourself in such a way, the language should NOT be Turing Complete.
Thus you should be writing everything in HTML.
A
Anon12/02/25, 10:05No.107404801
words words blogspam theory circlejerkThe big chunk allocation is arena allocation. You are right that is commonly used in graphics programming.If you have dynamic size, you can use size class allocator for a compromise. It's as simple as LD_PRELOAD=/usr/lib/libtcmalloc.so.4 or something . Literally a single line of code improved performance at FB
A
Anon12/02/25, 10:27No.107404903
With the "linear allocator that releases all memory at once" I always run into issues:- Overlapping lifetimes
Imagine you want to read a png file, decode the bytes, then free the original raw png bytes, but keep the decoded bytes. Then you can't free the raw png bytes. You have two options here.
Either just don't free, but that's like saying, I don't do memory management at all here. Could be fine if you have enough memory, but that just sidesteps the problem.
Or you have to pass in two allocators, e.g. one for temporary allocation, one for permanent ones you want to keep. That's only a little annoying in this scenario, and it's pretty clear what's temporary and what's permanent, but I always run into situations where I suddenly have to route a second arena down a bunch of calls or create a new one ad-hoc just to get some memory, and it gets messy quickly.- Growing data structures
Dynamic arrays are just so useful, but if you only have a linear allocator, you can only allocate at the top, you can only dynamically grow something if it happens to be the very last thing you allocated which is never the case in non-trivial situations. In the general case, you're just leaving the old memory behind. With a growth factor of 2, you'd end up needing twice as much memory for your array because of that fragmentation.
That's fine again if you have enough memory, but my point is that arena's just suck for this kind of allocation pattern. Regular allocators handle it fine.
And if you're starting to think about adding a list of free blocks to your linear arena that can hold the blocks that some other data structure grew out of, then you're essentially writing a bad general purpose allocator ad-hoc in your arena. Might as well use a generic malloc then.Sometimes there's clear scenarios where you're just allocating a bunch of stuff linearly, and then linear allocators are obviously great. But trying to force them into all other cases seems like a bad idea.
A
Anon12/02/25, 13:19No.107405986
You are basically talking about arena and they still don't protect you from out of bound access.
As soon as you deal with pointers you take the risk of accessing invalid memory regions.You could avoid it by always having a check that the address is valid but this is inneficient.Anyway, the issue has never been allocation itself but memory access patterns.
A
Anon12/02/25, 13:26No.107406052
I use specialized allocators a lot, especially "alternate" stacks, helps bypass shit like having no dynamically sized arrays in the language while still having the performance of the stack.
A
Anon12/02/25, 13:43No.107406217
Borrow checker is not a form of memory management. Rust uses same memory management model as modern C++(RAII).
Borrow checker is a static analyzer. You can attach similar tools to your C++ codebases too.
A
Anon12/02/25, 13:54No.107406297
Just use memory arenas
A
Anon12/02/25, 13:57No.107406323
Allocator-based memory management starts making sense when you realize that most of the time you have a plethora of different objects but they are part of the same system or program logic phase, so their lifetimes are bounded by a shared context. If you think about managing the memory in terms of individual objects, you have to either restrict or keep track of what's referencing what. On the other hand, if you know they're all going to be dead by a certain point, no matter how they reference each other, you can allocate and deallocate them collectively and never think about it.
A
Anon12/02/25, 15:21No.107406992
>Ginger Bill alleges this is not true, and that most of the time you really know how much memory you're dealing with. That opens up a new option:
This is wrong. After over a decade of programming, nearly all my programs use dynamic amount of memory that depends on input data, configuration, number of users/connections, etc.
>That opens up a new option:
>4. Allocator-based management
All the 3 forms of memory management you mentioned, including C, use allocators. What do you think malloc does?>From what I understand, the principle is to preallocate necessary memory to complete a task, complete it without worrying too much about memory efficiency within the task, and then release all the memory at once.
>Anyone try programming this way? How did it work in practice?
This has very narrow usecases. So far I only found memory areas useful in two kinds of programs. Raytracers which allocate a lot of temporary data that can be all released after frame is rendered and some games that have hard limit on amount of enemies or projectiles(object pools). In both cases, these areas are ofc allocated by dynamic memory allocation mechanisms.>I expect this would be very efficient for low-level computing
In low level computing, I just allocate heap and few statically known persistent allocations on my stack. With maybe some additional heap external memory(eg PSRAM) with independent (dynamic) allocator and that's it. I just write code that rarely allocates things and allocations are not that slow anyway.
A
Anon12/02/25, 15:29No.107407069
Another nocoder thread.
A
Anon12/02/25, 15:44No.107407234
Borrow chexking is orthogonal to memory management
A
Anon12/02/25, 16:01No.107407442
>Anyone try programming this way? How did it work in practice?
wtf?
arena allocators are a classical programming pattern in c>enter context : create arena
>leave context : destroy arenai use them constantly, everywhere.
nothing arcane.
you allocate a chunk and distribute pointers to it
if you run out of space, you allocate a new chunk
its a code organization measure as much as it is a performance enhancing measure because you cut down on actual allocations.
you allocate once per 1000? 100000 items?
your allocation time basically dissolves into nothing
A
Anon12/02/25, 16:11No.107407556
>Midwit is getting angry, heh.
Imagine being so trooned-out that you start believing crippling intrinsic limits on what programs you toy language can express (to the point where you can't even implement basic data structures) make it more expressive.
A
Anon12/02/25, 16:29No.107407737
it used to be that you had severe memory limits anyway, and you basically just used all of it, so you had to use it wisely.
A
Anon12/02/25, 16:30No.107407743
Recent cloudflare incident has proven that Rust is nothing more than pic related, you can stop pushing this shitlang now.
A
Anon12/02/25, 16:48No.107407963
cnile discord found this thread
A
Anon12/02/25, 17:10No.107408242
2 and 3 are the same lmao
A
Anon12/03/25, 04:00No.107414719
It's valid to pre-plan your exact memory usage and pre-allocate everything. Think of an 8-bit console game. They had specific memory addresses for things like score, health. If you had game "objects" appearing and disappearing, such as an enemy sprite appearing on screen, they had a set number of memory slots for the object data, they designed the game so that there was a maximum limit to the number of objects could appear on screen at any one time.In modern software, it's still viable. If you are reading user data, pre-allocate the buffer size. Use mmap to map files. The convenience of allocating memory when needed isn't necessary. If you have a complicated program that could do a variety of things (you don't know the memory requirements until it starts doing things), divide the program into modules so that each module knows its memory footprint and allocate and free memory per module as needed. Reducing ad hoc memory allocation is a reasonable style objective. If you can't do this there is a good chance your program has scope bloat.
A
Anon12/03/25, 04:03No.107414741
These numbers seem kind of retarded, isn't GingerBill a game developer? The lifetime of most memory allocations in a game are not known, you can't know how many bullets the player is going to be firing from his gun or how many enemies the level designer placed on the level
A
Anon12/03/25, 04:52No.107415036
void *mem = sbrk(4096);just keep growing the data segment every time you need memory
A
Anon12/03/25, 05:03No.107415137
a lot of this thread looks like the same guy replying to his own post
A
Anon12/03/25, 06:33No.107415714
>1. Leave it to GC
good enough for me and enterprise
A
Anon12/03/25, 10:37No.107417204
Well, this thread turned out to be extremely retarded.
A
Anon12/03/25, 11:56No.107417637
>request a lot of memory
>do everything you want in that memory
>release it all at once
i think this idea has been explored before
I've known them as arenas
https://en.wikipedia.org/wiki/Region-based_memory_managementI haven't done any serious programming but I imagine such an approach would be bad if your average memory cost was much lower than your worst-case memory cost. So perhaps if you were parsing a context-free grammar and needed to maintain a stack of non-terminals whose length should be say log n but in the worst case could be n.
A
Anon12/03/25, 12:01No.107417657
Maybe modern OS's have fancy memory prediction algorithms to predict whether some swap space needs to be used. Perhaps allocating massive chunks aperiodically would mess up that predictions.
There's also another type of memory management which is to do no frees and have the OS clean up after you termintate. Only good for short programs
A
Anon12/03/25, 17:00No.107419961
bump. indian shill posting hours