I've been trying to find a good algorithm to use for the malloc implementation in my C library. I know Doug Lea's malloc is the "traditional" way to go for this, but I don't like the memory overhead of storing various metadata in each allocated block, especially when allocating small things (like 2 dwords for a linked list). So, I've been thinking of using a sort of slab allocator modeled after what I think SLUB does in Linux. Here's a synopsis:
The slab allocator is just a bitmap based allocator that allocates only multiples of page-sized chunks (any request larger than a page is satisfied by this allocator directly). Each cache has a header of 4 dwords with a count of the number of allocated items in the chunk, a value for the size of each item in the cache, and two pointers to make a binary tree. When a slab is allocated, it is added to the tree, and its contents are made into a linked list, which is added to the appropriate bucket. The tree of headers is used to find which cache a freed pointer belongs to (and implicitly, what size it is), so the cache can be freed if it is empty. Pretty basic.
So here's my question: are the allocation patterns in userspace programs regular enough to make a slab allocator efficient? Afaik, the reasoning for using a slab allocator in a kernel is that there is a small, fixed number of structures used, so reuse of the same sizes is predictable. And is my design a reasonable way of making a slab allocator? Or am I completely misinterpreting something?
using a slab allocator for libc malloc
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California