std.allocator issues

[Marco Leise via Digitalmars-d]

Am Sat, 20 Feb 2016 08:47:47 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 02/20/2016 12:39 AM, Steven Schveighoffer wrote:
> > Given that there is "goodAllocSize", this seems reasonable. But for
> > ease-of-use (and code efficiency), it may be more straightforward to
> > allow returning more data than requested (perhaps through another
> > interface function? allocateAtLeast?) and then wrap that with the other
> > allocation functions that simply slice the result down to size.
> 
> Actually I confess that was the exact design for a while, and I, too, 
> found it ingenious. You ask me for 100 bytes but I'll allocate 256 
> anyway, why not I just return you the whole 256? But then that puts 
> burden everywhere. Does the user need to remember 256 so they can pass 
> me the whole buffer for freeing? That's bad for the user. Does the 
> allocator accept 100, 256, or any size in between? That complicates the 
> specification.

I found it ingenious, too. The question how much room was
really made free is common in programming. Aside from memory
allocations it can also appear in single reader/writer
circular buffers, where the reader consumes a chunk of memory
and the waiting writer uses `needAtLeast()` to wait until at
least X bytes are available. The writer then caches the actual
number of free bytes and can potentially write several more
entries without querying the free size again, avoiding
synchronization if reader and writer are threads.

Most raw memory allocators overallocate, be it due to fixed
pools or alignment and the extra bytes can be used at a higher
level (in typed allocators or containers) to grow a data
structure or for potential optimizations. I think for
simplicity's sake they should return the overallocated buffer
and expect that length when returning it in `free()`. So in
the above case, 256 would have to be remembered. This is not a
conceptual burden, as we are already used to the 3 properties:

ptr, length = 100, capacity = 256 

By the way: jemalloc has `mallocx()` to allocate at least N
bytes and `sallocx()` to ask for the actual size of an
allocation.

-- 
Marco