Formal Review of region allocator begins

Robert Jacques sandford at jhu.edu
Sun Sep 18 20:56:44 PDT 2011


On Sat, 17 Sep 2011 23:28:58 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> Ok, implemented.  It definitely makes the design cleaner.  Thanks again.
>   The delay was just because I had waited a while to see if any other
> comments came up that would make me change my mind or turn the whole
> design upside down.
>
> Code:
>
> https://github.com/dsimcha/TempAlloc/tree/master/std/allocators
>
> Docs:
> http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_allocator.html
> http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_gc.html
> http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_region.html

Here's a couple of thoughts on the allocator API design, given my experience with appender:

1) Regarding: void* allocate(size_t nBytes);
You should be able to allocate memory and specify the GC block attributes (scanning in particular). i.e. something like

auto ptr = alloc.allocate(128, Allocator.BlkAttr.SCAN); // See GC.BlkAttr and GC.qalloc

By correlation, void* free(void* ptr); also needs to take a BlkAttr. i.e. so that a region allocator could then remove scan from a memory block, etc.

void* allocate(size_t nBytes, Allocator.BlkAttr blkAttr = Allocator.BlkAttr.NO_SCAN);
void* free    (void* ptr    , Allocator.BlkAttr blkAttr = Allocator.BlkAttr.NO_SCAN);

2) Regarding: bool resize(void* ptr, size_t nBytes);
You should be able to specify both the desired and a minimum number of bytes for the resize operation. Also, in terms of nomenclature, I like 'extend' better as 'resize' implies a realloc in my mind. i.e.

alloc.resize(ptr, 128+4, 128+128); // See GC.extend

size_t resize(void* ptr, size_t minBytes, size_t nBytes);
//alternatively, have separate resize and extend routines.
bool   resize(void* ptr, size_t nBytes);
size_t extend(void* p, size_t minBytes, size_t maxBytes);

3) Regarding: size_t allocSize(size_t nBytes);
This function only needs to be used if the allocator allows variable sized allocation blocks (like the GC). A static bool to flag this would be amiable to conditional compilation.

4) Regarding: size_t alignBytes(size_t nBytes);
The documentation of this needs to be improved. Specifically, there is no guarantee that the function will behave 'sanely'. i.e. does

alignBytes(N) <= alignBytes(M) && N <= M

hold true? And what's the value of alignBytes(0)?


More information about the Digitalmars-d mailing list