I'm working on a C project for which I'm going to use a custom allocation scheme. I would like to have several memory arenas which I can allow to grow as much as necessary to accommodate the needs of the user. I would like to explicitly place the arenas in my 64-bit address space so as to spread them out approximately evenly, minimizing the chance that one arena will ever grow large enough to collide with another and force its reallocation.
This scheme relies on being able to know that no stray allocations will be made between the current end of one arena and the start of the next. However, I will be using winAPI for my GUI, which will presumably allocate in my address space, and as far as I can see, I can't dictate to its allocators where they're allowed to do so. It seems that instead, I would have to specify everywhere it isn't allowed to allocate by calling VirtualAlloc with MEM_RESERVE, and since the wider the arenas are spaced, the better, I would prefer that to entail as much of my address space as I can get away with.
So...would making a reservation of such a large span cause any kind of pathological behavior? People have suggested that it would gunk up Windows' system for tracking virtual memory, but never with a concrete enough explanation of how to convince me to give up on the idea. I understand that for committed memory, the OS must enumerate each page since it needs to specify how the page is mapped to physical memory. In other words, the amount of work scales with the amount of memory committed. If memory that is merely reserved is treated the same way, then my large reservation would indeed stress the system. However, since reserving lacks the complication of mapping to physical memory, I can imagine that instead of enumerating each page, it only keeps track of the start and end of each reservation. In that case, the amount of work would scale with the number of reservations, and my giant reservation would be no worse than reserving a single page.
What I have tried:
Reading about the Windows virtual memory model.