Re: RFC: Slab-o-rama (after Rene's suggestion)

Hey Axel,

On 4/23/07, Axel Dörfler <[email protected]> wrote:
> > Please ignore the code style. :-)
>
> Eeek :-)

  Just considering this is a sort of initial prototype, the code style
will be "fixed" meanwhile.

> I have a couple of comments:
> 1) you can't use malloc in the slab allocator at all - it's supposed to
> replace our malloc implementation

  Yes, i know. The malloc backend is there just for testing. In fact
its not even using malloc but posix_memalign. I believe this backend
independence is important so we can more easily re-use the same
infrastructure for user-space applications. I'll add a backend which
allocates blocks through VM areas to be used inside the kernel.

> 2) you can't (easily) use STL in the kernel (no exceptions), also it
> must not use malloc either

  Again, for testing only. :-) The RBTree strategy should in fact be a
Hashtable strategy and use an self-extending hash table. I used
std::map to quickly show how a strategy which uses external linkage
could be implemented. The only STL bits i really use are std::new and
std::swap.

> 3) a hard part of the slab allocator is the backend, as it has to work
> directly on the VM, and yet, it shouldn't collect too many areas

  Yes, Bonwick's also introduces a very nice resource allocator in his
2001 paper which i'm planning to implement as well. We could use it
for most resources, including FDs, ports, etc.

> 4) we don't export any C++ APIs from the kernel; IOW the implementation
> will be local to the kernel

  I would rather have this as standard internal interface sitting in
libroot which the kernel would use as well. So the C++ API would be
exposed in libroot, not the kernel (as well as the C interface). I
really think some of our user-space stuff could benefict from a slab
allocator, thus my consideration of adding it to libroot.

> 5) a public userland API shouldn't be added for now, though a private
> one might be nice, especially for replacing the current BMessage
> allocator (and eventually BBufferCache's backend, too).

  Right, my idea was a private interface to be used by internal components.

  Hugo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/