Brett Lymn <[email protected]> wrote: > > I am not convinced about statistics point. For intensive allocations, > > constant-sized pool_cache(9) should/would be used, where it already > > gathers statistics. If there is some particular need for statistics, > > one can always collect it at the caller's level. Therefore, I do not > > see the need to invade allocator's API for that. > > > > We shouldn't just consider statistics anyway, there were some useful > malloc debug facilities which allowed you to know what memory had been > allocated to what process. I had extended that so you could tell what > processes had allocated next to the region of interest - I used this to > nail a rather nasty buffer overflow that was stomping on the memory > allocations of innocent parties. I don't know how I could have tracked > that bug down without the level of information available from the malloc > debug logs.
Supposedly, it can be developed for kmem(9) as well. This does not seem to be related to malloc's M_* types, though. Also, I will point out that kmem(9) has kmguard facility to find underflows/overflows (see bottom of the kmem(9) manual page). -- Mindaugas
