On 2010-07-10 at 01:30:52 [+0200], Lucian Adrian Grijincu <lucian.grijincu@xxxxxxxxx> wrote: > I've been chasing a SLAB bug all last night and today, only to find > out that it was from my code (the one I double, tripple checked before > deciding it must be from the SLAB). > > SLAB had no fault, but because I found no documentation about the > inner workings of Haiku's SLAB allocator I wrote down some notes. > > Ingo, or anyone more familiar with the code: I you find any value in > including these notes in docs/, I've attached them. > > Warning: these are based on a fast shallow reading of the code, and > may be completely and utterly wrong. Thanks. I quickly scanned the text and it seems accurate. I'm not sure how helpful the implementation notes are for people not familiar with the slab allocator. I don't have the link at hand, but there's a paper by Bonwick which describes the slab allocator in detail. Our code implements most of the features very similar to how they are they described. So once one has read through the paper it should be rather easy to understand the code. Though, admittedly, it's far from beautiful. Regarding the debugging notes, you're right, the current implementation isn't particuarly well suited for debugging memory issues. That's why until recently we didn't use the slab allocator as malloc() backend. Axel only switched recently, because a change in the memory allocation pattern in the boot process exposed a heap issue that no one was motivated or had the time to tackle. Anyway, we should really improve the slab debugging features. CU, Ingo