21–30 of 44 posts
Every time I hear someone talking about writing a memory allocator, it always reminds me of the brilliant CppCon 2015 talk by Andrei Alexandrescu about how he wrote an modular allocator library that can be built up in pieces to make whatever you like. https://www.youtube.com/watch?v=LIb3L4vKZ7U
Every time I hear someone talking about writing a memory allocator, it always reminds me of the brilliant CppCon 2015 talk by Andrei Alexandrescu about how he wrote an modular allocator library that can be built up in pieces to make whatever you like. https://www.youtube.com/watch?v=LIb3L4vKZ7U
I also really like John Lakos' talks on allocators. He does a great job of systematically decomposing the problem space.
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 know how; and actually useful allocators are made by people who don't write tutorials about it.
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.
Earlier quoted context omitted.
I also really like John Lakos' talks on allocators. He does a great job of systematically decomposing the problem space.
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…
Earlier quoted context omitted.
I also really like John Lakos' talks on allocators. He does a great job of systematically decomposing the problem space.
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…
Earlier quoted context omitted.
I also really like John Lakos' talks on allocators. He does a great job of systematically decomposing the problem space.
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…
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…
Thread-based allocators are a bit overrated. In apps it’s quite common for objects to migrate across threads, especially from workers to the main thread.
What happens with the object afterwards is not relevant.
Earlier quoted context omitted.
Thread-based allocators are a bit overrated. In apps it’s quite common for objects to migrate across threads, especially from workers to the main thread.
That's not the point at all. Having a per-thread pool means synchronization-free alloc. What happens with the object afterwards is not relevant.
Earlier quoted context omitted.
That's not the point at all. Having a per-thread pool means synchronization-free alloc. What happens with the object afterwards is not relevant.
But objects are passed around between threads and another thread might want to free it?
Edit: wrong, I re-checked. The solution to this is that marking an object as free is lock-free. The freed objects do not immediately change thread pools.