Okay. Onto the next item in the review queue. I'm going to be the review manager this time around, and we're going to be reviewing dsimcha's region allocator. The review starts now and will end on 2011-09-21 at midnight in UTC (so about 2 weeks from now, when the 21st begins). Assuming that we're ready to vote at that point, I'll start a thread for voting for inclusion in Phobos, and the vote will last a week. If it's not ready to be voted on for some reason (such as dsimcha needing to go back and make a bunch of changes that are going to need to be reviewed), then voting will be postponed and it'll be put back in the review queue once it's ready for review again.
Docs: http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html Code: https://github.com/dsimcha/TempAlloc Description (from docs): RegionAllocator is a memory allocator based on segmented stacks. A segmented stack is similar to a regular stack in that memory is allocated and freed in last in, first out order. When memory is requested from a segmented stack, it first checks whether enough space is available in the current segment, and if so increments the stack pointer and returns. If not, a new segment is allocated. When memory is freed, the stack pointer is decremented. If the last segment is no longer in use, it may be returned to where it was allocated from or retained for future use. Some additional issues that dsimcha wants to mention for the review: 1. This is both a proposal for RegionAllocator and a proposal for a more general allocator API in Phobos. The allocator API will be a structural interface that includes the intersection of gcallocator and regionallocator functionality. I don't have a more precise definition yet. Hopefully the review process will hammer out whatever ambiguities remain. 2. Should we put this stuff in a std.allocators package, in a single std.allocators module, or something else? 3. We definitely want a reap (combination region and heap) eventually, though I don't have one yet. I want RegionAllocator to be reviewed for anything that would make it unnecessarily hard to write other allocators on top of it, most importantly reaps but also free lists, etc. This is the first code to be reviewed which implements Andrei's proposed allocator API, and several projects (including the GSoC projects) rely on it, so it is critical that this code get a thorough review. It will have a large impact on D for years to come. So, review away! - Jonathan M Davis
