> > cdunn2001: I still would like to see freelist sizes. > > I'm not sure what you mean by that. Large blocks in the allocator (type > BigChunk) are kept in a single list and are allocated using first-fit. Unless > you are also allocating a lot of small objects, the amount of free and used > memory should be a reasonable approximation in your use case.
Yes, I also have lots of small allocations. At Amazon, in C++, I used a vastly different scheme, which would work beautifully here. The main thread managed sufficiently large contiguous regions of memory. Each thread would take the regions it needed, allocate blocks sequentially within them, and leak everything. At the end of a job, the thread would return all its regions to the main region manager, which would zero them out (for security concerns), and that thread would be returned to the threadpool. That's simple, secure, and extremely efficient. It's difficult to do in Nim (or in Rust, last I checked) because I cannot provide my own memory manager for portions of the code.
