CppCon 2015: Andrei Alexandrescu “std::allocator...”

—
std::allocator Is to Allocation what std::vector Is to Vexation
--
—
std::allocator has an inglorious past, murky present, and cheerless future. STL introduced allocators as a stop gap for the now antiquated segmented memory models of the 1990s. Their design was limited and in many ways wasn't even aiming at helping allocation that much. Because allocators were there, they simply continued being there, up to the point they became impossible to either uproot or make work, in spite of valiant effort spent by the community.

But this talk aims at spending less time on poking criticism at std::allocator and more on actually defining allocator APIs that work.

Scalable, high-performance memory allocation is a topic of increasing importance in today's demanding applications. For such, std::allocator simply doesn't work. This talk discusses the full design of a memory allocator created from first principles. It is generic, componentized, and composable for supporting application-specific allocation patterns.
—
—

*-----*
*-----*

[davidleimbach]

It was as if he was dodging a sniper. Agreed. The camera operator nailed it!

[Sebanisu]

This guy is hilarious! :D A joy to watch and learn from.

[JohnDlugosz]

In 1983, the C programming language did *not* have a void* type. We used char* and at least some of us used a typedef to indicate I really had unspecified stuff (I used 'ambi'). The void and void* types, along with features like allowing different structures to have members of the same name, were added later.

[HebaruSan]

I read two of his books and I had no idea he was hilarious in front of an audience. Frankly I expected the opposite!

[renliu]

So, such allocator, as described by Andrei, does it exist? Or it's yet just an idea for future C++?

[DatMiluK]

This was one of my favorite talks, and I've seen a lot! He is very informative and at the same time pretty funny. And he is also the first person who successfully tought me that *int is a type*. The brainfk was huge when I finally realized it. xD

Best man!

[danielphd]

Thank you very much Dr Andrei Alexandrescu

[olovik]

28:20 "not having to be intelligent is a good sign" in design

[michaelmoser]

1:12 - you don't need to keep the file and line number, it is enough to keep the return address (__builtin_return_address on gcc), you can then get the source/line number from debug information (addr2line).

[jasonphaslam]

This is great! I'm a huge fan of Andrei. He gave a similar talk about allocators in D. I was hoping for a C++ treatment of the same topic.

What's with the comments about no profilers on OS X? I don't know why he would think that. Does Instruments not fit the bill?

[JohnDlugosz]

operator new is a function essentially the same as malloc. No type information. It does not call constructors. You mean to refer to a "new expression" which uses the keyword and has complex behavior implemented by the compiler, which includes calling operator new, checking the result, and calling the constructors.

[dexterman]

How does one use these in any meaningful way, without reinventing the stl? As in, passing these allocators to std::vector won't work.

[xfreeman]

Andrei makes it sound like goodSize is useful for wrapping the argument to allocate, but why not just have allocators return the good size (the actually allocated size, and not the requested size) in Blk, which callers can read to find out how much they really got? Is there any other use for goodSize? Any reason to know goodSize without calling allocate?

[jonaskoelker]

It looks to me like the freelist allocator has the fallback allocator baked in.

I would think the whole point of designing for composition is that you can separate those two parts.

The simpler free list allocator then becomes:

allocate(size) { if (size is wrong or free list is empty) return null; else return head of free list }
owns(p) { p.size == mysize }
deallocate(p) { assert(p.size == mysize); prepend p onto the free list; }

When combined with a fallback allocator, you should get Andrescu's free list allocator.

[finnw]

51:33 this line contains a bug:

return b.length == s || parent_.owns(b);

In a FallbackAllocator<FreeList, X>, the FreeList will falsely claim to own a block that really belongs to X, if the size happens to match.

[ddddddddd]

On slide 29 the `owns` should have && instead of ||, no? The size needs to be the same and it needs to come from the parent allocator. Also, this assumes that no two FreeList for the same size will be created with the same parent allocator.

[embeddor]

I had to implement such allocators in C for a "standard" library for embedded systems in my company and man I wish I had C++ templates for that. I had to use macro-based templates instead which I wish on no enemy.

[walterbz]

'allocators should only care about size, alignment' ... but the type could give hints as to useage, or lifetime (as defaults, and you could override that with explicit hints)

[mateferencnagy-egri]

The things he describes do not integrate well with the current STL implementation. In fact, that is one of the keystone statements. The next iteration of the STL (aka. STL2) is currently being designed which will be a complete revamp of everything. The STL has many historic garbage in it that are rooted too deeply into the entire system. Allocators for one is one such entity. You cannot change its API without having to touch just about everything.

[TheFerdi]

just found the hole in my argumentation: you don't get size_t as an input in free() in an std::allocator, do you? so you'd have to keep track of that seperately. This sucks >.<