std.allocator needs your help

Peter Alexander peter.alexander.au at gmail.com
Mon Sep 23 13:37:29 PDT 2013


On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu 
wrote:
> 1. Typed allocator, i.e. every request for allocation comes 
> with the exact type requested;
>
> 2. Untyped allocator - traffics exclusively in ubyte[].

This is a good design.

Perhaps this is a later concern, but we should make sure that 
node-based containers (e.g. linked list, trees) have a way to 
access the allocation size needed for the node. STL did not do 
this.


> * alignment is a compile-time constant yielding the alignment 
> of allocated data. Many allocators offer the maximum alignment 
> of the platform (for which I used real.alignof above). This 
> constant is required for all allocators.

What if, for example, I wanted to allocate a 4096 byte aligned 
block from the GC allocator? Do I have to create a new allocator 
backed by the GC allocator?

What if the alignment is not known at compile time (e.g. hard 
disk page size or CPU cache line size)?

Might be better to pass the desired alignment in the allocate 
method.


> * available is a property that returns how many total (not 
> necessarily contiguous) bytes are available for allocation. The 
> NullAllocator knows statically it has 0 bytes available so it 
> implements it as an enum. Generally allocators will implement 
> it as a @property. This property is optional.

It would be useful to know the maximum available contiguous block 
size too, so that you can find out if an allocation will succeed 
without calling allocate. It's also useful for diagnosing 
fragmentation issues e.g. "allocation failed, free memory = X, 
max contiguous = Y". If X is high and Y is low then you are 
highly fragmented.

Of course, this should be optional.


> * allocate(s) returns a ubyte[] with length at least s, or 
> null. (It does not throw on out-of-memory because that would 
> hurt composability; it turns out many elemental allocators do 
> naturally run out of memory.) This method is required for all 
> allocators. In most allocators this method should be @safe.

What are the semantics of allocate(0)? malloc(0) is 
implementation defined.


More information about the Digitalmars-d mailing list