Modern Linux memory management

[Yedidyah Bar-David]

On Thu, Jan 26, 2012 at 10:54:56AM -0500, Ori Berger wrote:
> On 01/26/2012 10:16 AM, Baruch Siach wrote:
> 
> >>Only by using valgrind, that I could find the exact location and figure
> >>out, that it was another function that had the problem.
> >>
> >>How does the modern memory management system is working then, that it takes
> >>so much time for the problem to surface ?
> >
> >Now, if you corrupt the internal glibc data structure, glibc won't notice
> >until you try to call one of malloc(), free(), etc.
> 
> And in addition to what Baruch said:
> 
> Valgrind will always catch these errors, but will result in
> significant slowdown (x10-x20). There are tools like DUMA (and its
> earlier incarnation, Electric Fence) incur almost no CPU overhead
> and can detect many kinds of corruptions as soon as they happen, by
> using the memory management units.
> 
> (Because of the MMU granularity, you need to run your program twice
> - one in which allocations are aligned to the lower address, and one
> when they are aligned to the top address)
> 
> There is also a middle ground; gcc's mudflap
> <http://www.stlinux.com/devel/debug/mudflap> and -- if your program
> is pure C and can be compiled by tcc,
> <http://bellard.org/tcc/tcc-doc.html#SEC21>; These are comparable to
> valgrind in functionality (for code you compile with them; standard
> library code runs at full speed/unchecked), but usually only
> introduce a small slowdown (10% or so).

BTW, in case you do not know Fabric Bellard, he does lots of very cool
stuff - he is the author of qemu, and every now and then I give a look
at his site. I now did because of this post and found out an amazing
project of a PC Emulator in Javascript:
http://bellard.org/jslinux/
The guy is simply amazing.
-- 
Didi