C++ memory allocator architecture

Question

I need to write Hoard allocator for C++ under Linux. While algorithm is quite simple, i don't understand, where (and how) to store allocator data (heaps, for example)

That's how i see it: allocator is not a process, it's a set of functions, which any application can use. Every app has it's own heaps.

1. What's going on, when app is starting?
2. And how allocator finds out, that heaps are already created?
3. How allocator creates, stores and destroys (when closing app) heaps?
4. When function is called, how to find out, in which thread (or on which processor) it runs?

Answer 1

1. Probably not much happens during app startup, unless the allocator is designed and hooked into the application startup code to preemptively request some memory from the operating system.
2. Heaps aren't really created. The allocation system goes out and asks the operating system for some memory when it needs some - either for its initial setup or later when it needs extra to fulfill a requested allocation. On unix-like systems, the system call often used is called sbrk . (Strictly speaking, on linux, sbrk is a library function wrapper for the brk system call - that may or may not be an important distinction for you.)
3. The allocator gets memory from the operating system using the sbrk call mentioned above. After that it's on its own to manage that memory. When the application exits, the operating system reclaims the memory - it knows what it handed out via the sbrk calls, so it knows what memory it needs to take back.
4. It almost never matters what thread or processor a given piece of code is running on - if you explain the context of what you're asking a bit more, I'll try to answer.

Answer 2

What's going on, when app is starting?

When the application starts up, the allocator initializes itself. You can do this on the first call to your allocator if you wish.

And how allocator finds out, that heaps are already created?

I'm not sure I follow the question. If you're talking about heaps that are managed by code that uses this very allocator, then it finds out because it creates tracking entries when it created the heaps. If you're talking about heaps in other processes or created by other allocators, it doesn't care since it can't use those heaps anyway.

How allocator creates, stores and destroys (when closing app) heaps?

Generally you have a low-level and high-level allocator. The low-level allocator just gets raw chunks of memory from the operating system. The exact mechanism is platform-specific. The high-level allocator manages the heaps and it gets the memory to hold heap structures from the low-level allocator.

When function is called, how to find out, in which thread (or on which processor) it runs?

You can find out which thread with either thread-specific data or by calling a platform-specific "get thread ID" function. As for which processor, it's very platform-specific and the information may be obsolete by the time you get it. Most platforms do have such a function -- just remember that you can only use it as an optimization (to reduce lock contention or for cache hit rate improvement). Critically, you cannot use it to bypass locking because a thread can move from one processor to another at any time.

Honestly though, memory allocation that provides good performance and is portable across platforms really is a case of heavy wizardry. If you're not an expert in the area, it is very unlikely that you would be able to develop an allocator that provides the performance and stability you need for a production application.

Answer 3

What do you mean "write Hoard allocator"? Someone already wrote this allocator. Are you trying to use it from C++? Emery Berger's Hoard's inner workings are described in quite a lot of detail in a white paper Hoard: a scalable memory allocator for multithreaded applications . Whatever that doesn't answer can always be resolved by reading the source or contacting the author. I'd be surprised if there isn't a mailing list.