Hacker News Reader

Comment by sakras | Hacker News Reader

I like this a lot! I’ve been trying to find ways to avoid memory allocation as much as possible in my projects as well. So far I’ve settled on mmap-ing large slabs at a time and arena allocating (Linux’s mremap makes growing the allocation really efficient too!).

However, come to think of it just using a fixed amount is just as good if not better, since I’m always going to be constrained by memory in some way anyway. And if I allocate e.g. 80% of the system’s memory upfront, it won’t _actually_ be mapped by the OS until I touch it. There may be some interesting stuff with using huge pages for the first few pages and use smaller and smaller pages as you approach your memory limit. Definitely will give this a try!

View on HN

> if I allocate e.g. 80% of the system’s memory upfront, it won’t _actually_ be mapped by the OS until I touch it

What about people running vm.overcommit_memory=2

In practice that's a broken config because any program that uses the fork syscall will hog all your memory.

(Yes fork-exec is stupid, but there's not much you can do about it)

Yes, this approach is followed as well, but now you're at the problem of writing a memory allocator by yourself (which might of course turn out to be better for your usecase). So the issue of writing code that avoids allocation still prevails, as now you probably want to know what to allocate memory for, since if you were supposed to make a general purpose allocator, it is likely it won't overperform libc malloc.

I agree on some level, but I think if you’re intentional with your design you can get by with a very simple arena allocator where an allocation is a single subtraction from a pointer.

In my experience, most programs have a few long-lived data structures that can be initialized up front, and then lots of small data structures that are created and destroyed frequently. If you do it right, you can put the long-lived guys at the beginning of the arena and then just wiggle your arena head pointer back and forth for the small guys.

This does take some more thought and consideration, and is definitely a bit trickier than just using malloc when you need it, but for me the trade off is worth it (for one I gain some amount of satisfaction from imagining my data all neatly in a row).

I use a double-ended stack allocator for most allocations in personal C projects. The second end adds a significant amount of flexibility; temporary allocations can accumulate at one end of the stack without preventing a longer-lasting allocation from being made later (yet before the temporary allocations can be freed) on the other end.

Oh that's also great! Thanks for the tip, I'll have to incorporate it!

Reply on news.ycombinator.com