Memory Leaks

Memory leaks are plaguing our gadget - heavy life. Most of the electronic devices we use, from game consoles to mobile phones to digital cameras to personal navigation devices to netbooks and beyond. All of them are computers in fact. A microprocessor, memory, storage and software running on top of the classic Von Neumann architecture. Processors are faster and faster and software becomes more and more complex, very often running away from initial frames it was designed to stay within. Software running away usually means weird behavior of an application or execution slowdown or loss of functionality. Software running away usually means memory allocation problems hidden deep inside. Software programs spend most of their time allocating and releasing blocks of memory. When there is continuously less memory freed than allocated, we have a condition called memory leak, ending up in a situation when all available physical memory is eaten by an application and no more can be allocated causing the program to stop or the entire computer to freeze or reset.

When it comes to memory leaks, a lot of them are linked to the general architecture a given platform (hardware and software) is based on. Architecture of software design and implementation and how much an operating system helps in detecting leaky applications and prevents one faulty application from affecting the other running in parallel. I would even risk a statement the memory handling abilities of a platform may be the main factor related to it's commercial success.

Some of you remember Windows 95 and how much of a bad image Microsoft owes to this operating system for its famous and notorious crashes. Much more stable Windows NT was not popular at that time and it took years for Windows XP to regain the faith of the users. Looking from a perspective, Windows XP did an excellent job convincing users a computer platform can run for months without resetting. But things seem to get worse now, new wave of applications seem to eat memory faster than anytime before.

There are two software environments that in my opinion are having significant problems handling memory. One is Symbian, known as one of the most difficult platforms to write programs for. The other one is Garmin, with its proprietary platform. I have Garmin on board in my car and it is not unusual that it just resets when navigating to a destination or just occasionally when I touch the display trying to invoke one of supplementary functions. At 3GSM World Congress I was surprised to see the new phone / navigator by Garmin on display, showing a "not enough memory to calculate the route" message. Really not something to be proud of in 2009. Of course the memory / OS problems did not prevent Garmin from reaching the top spot in the personal navigation devices market. But these problems may significantly suppress Garmin's aspirations to enter mobile phone market with the NiviPhone line.

While iPhone did it right (I never experienced a freeze or reset using iPhone), BlackBerry on the other hand is not without issues. So called battery-pull procedure is well known among the BlackBerry community, being offered as a remedy for many software glitches. Something goes wrong on a BlackBerry? Remove the battery, wait a few seconds and put it back... Forced restart of a platform. Good thing is it seems you are unlikely to lose data with that, but really... this is not something users should be doing. And applications like the QuickPull are just the proof of how bad the state of memory management really is in the industry....

I wish developers paid more attention to defensively design and implement their applications. I wish marketing managers gave development teams more time to stress test the software. And in the end... I wish users started picking their devices allocating more weight to device stability versus features....