During my years working in different teams at different companies, I was struck by the general lack of understanding about memory. The most common mistake was the classic “Linux ate my RAM problem“, a “bug” regularly reported, sometimes several times for the same project in just a few months. Others include developers relying on the lack of swap space in a uniprocessor system with a single process to assume “real-time” behaviour. Processor caches were practically never thought of. People seemed to accept extremely poor performance as normal. I once had to explain how I achieved a seven-fold increase in performance by replacing lots of send/recv/realloc/memcpy calls with shared memory because clients were suspicious that something important had been omitted. Endianness, alignment and reference counting were often afterthoughts. Reference counting isn’t easy, and adding it afterwards is even harder, leading to situations where leaking memory and rebooting every week or so becomes the “solution” to the crashes caused by the lack of reference counting. Developments of code managing low-level communication with devices were mostly dead ends, from screens flickering to entire machines configured with write-through caching to avoid random data corruption.
From my point of view, which is the point of view of an open-source software developer with some experience with demanding projects, such as Linux and other Unix-like systems, it’s a disaster. It encourages a vicious cycle where people grow naturally distrusting of one another, and leads to huge debugging overheads. The company I work for, Novasys Ingénierie, organizes internal technical presentations so that engineers who wish to improve on a particular subject can learn from the expertise of others. I used the occasion last April to offer a small presentation about memory, how software engineers should think of it, and basic techniques to do things well :
Memory Management – A View for Software Engineers
This is a presentation only, without the oral annotations that usually go along such things. For those who really want to get into the details, I highly recommend to read the famous paper by Ulrich Drepper : What Every Programmer Should Know About Memory.