Live data from Hacker News

Writing a Memory Allocator (2019)

dmitrysoshnikov.com

31–40 of 44 posts

Re: Writing a Memory Allocator (2019)

#31

Implementing a memory allocator seems to require system calls. What happens when there's no OS? For example on an MCU like Arduino, is the memory allocator packaged along with the program data? If so and in the case of an Arduino, is the code for it available anywhere? I would be curious to see how this is implemented on an embedded system.

You could fairly easily implement a bitmapped memory allocator which hands out chunks of reserved memory. I think you could build a more complex allocator on top of that if needed. For a lot of embedded applications, you really want to avoid dynamic memory allocation though. Use mempools if you need dynamic memory, which will at least limit fragmentation.

Second this. It’s really easy to fragment memory, and for long running embedded systems it’s not uncommon for free() to be a nop. I had to implement malloc just last week to access psram, and after doing a little research decided all I needed was an offset and some byte alignment. Since I never needed to deallocate the memory, it was very simple code.

Re: Writing a Memory Allocator (2019)

#32

I remember I did a memory allocator incompletely, and it did increase the speed of my application, but then debugging memory problem become less ideal because valgrind couldn't tell about memory boundaries any more. Make sure you put proper guard in debugging to trigger segfault :)

Valgrind comes with C macros for exactly that kind of use case: you can inform it about the state of your custom allocator, i.e. which parts of the heap are available/forbidden when this differs from its own tracking of the system calls and malloc usage.

Re: Writing a Memory Allocator (2019)

#33
post #26
post #22

Earlier quoted context omitted.

The only problem is that he is wrong on almost every detail. He has apparently never heard of mmap, which is awkward because mmap is how memory is obtained, nowadays. And if you want, you know, performance, it needs to know something about threads, pre-allocating chunks to assign to threads, and batching free ops per thread. Most of what you can find about writing allocators is written by people who don't actually kn…

Can you explain what you mean by mmap is how memory is obtained nowadays?

mmap is not only to map a file content into a process address space, it can also be used to request memory from the OS using the MAP_ANONYMOUS flag. Early on a malloc-like allocator would use brk/sbrk to get a chunk of "raw" memory, and manage this for the user providing access using malloc/free. Nowadays the same "raw" memory can be obtained using an anonymous map. A raw pool, when unused, can be returned to the OS by unmapping it.

Using an anonymous map provides address space randomization by default (for the raw pool location), whereas brk/sbrk extends a limit and because of this are predictable.

Re: Writing a Memory Allocator (2019)

#34

Implementing a memory allocator seems to require system calls. What happens when there's no OS? For example on an MCU like Arduino, is the memory allocator packaged along with the program data? If so and in the case of an Arduino, is the code for it available anywhere? I would be curious to see how this is implemented on an embedded system.

Here is for example a memory allocator used in micro:bit https://github.com/lancaster-university/codal-core/blob/mast...

It's quite simple and extensively commented.

Re: Writing a Memory Allocator (2019)

#35
post #32

I remember I did a memory allocator incompletely, and it did increase the speed of my application, but then debugging memory problem become less ideal because valgrind couldn't tell about memory boundaries any more. Make sure you put proper guard in debugging to trigger segfault :)

Valgrind comes with C macros for exactly that kind of use case: you can inform it about the state of your custom allocator, i.e. which parts of the heap are available/forbidden when this differs from its own tracking of the system calls and malloc usage.

Address Sanitizer has the same.

Re: Writing a Memory Allocator (2019)

#36
post #26
post #22

Earlier quoted context omitted.

The only problem is that he is wrong on almost every detail. He has apparently never heard of mmap, which is awkward because mmap is how memory is obtained, nowadays. And if you want, you know, performance, it needs to know something about threads, pre-allocating chunks to assign to threads, and batching free ops per thread. Most of what you can find about writing allocators is written by people who don't actually kn…

Can you explain what you mean by mmap is how memory is obtained nowadays?

sbrk isn't even supported on some platforms anymore, if I'm not mistaken

Re: Writing a Memory Allocator (2019)

#39

I built a memory allocator for testing not too long ago that only allocated but no-op'd deallocate(using the C++ Allocator interface). It was quite amazing that it resulted in a 25-50% performance boost in many cases I was testing. It's not for real code as you only get destruction but not deallocation. It let me pull that part out of the tests to get a better view of the performance

In case you weren't aware, this is a common enough technique for it to actually have a name: bump allocation. It's very useful in short lived programs with bounded allocations, for the exact reason you outlined.

The dmd D compiler adopted this approach and got a significant performance boost. [0] Looks like it still uses a pointer-bump allocator today. [1]

[0] https://web.archive.org/web/20190126213344/https://www.drdob...

[1] https://github.com/dlang/dmd/blob/025caed79/src/dmd/root/rme...

Post reply on HN