Wiki > Main > WhyNoMalloc (compare)
Difference: WhyNoMalloc (r3 vs. r2)
One of the first things that stump many developers coming into Rockbox is the lack of malloc(). Dynamic memory allocation is so common in "normal" programming that some people find it difficult to adjust their mindset to the concept of no-malloc programming.
So what are the reasons we don't want to use malloc?
We want to maximise the size of the audio buffer in order to minimise the requirements for harddisk access (hd spinup uses a lot of power). This translates into longer battery life.
Dynamic memory requires a heap, the area of unused memory from where malloc grabs the memory your code is requesting. This means there must always be unused memory available, i.e. we cannot at any time use all of the available memory on the device. This means a smaller audio buffer, more spinups and hence shorter battery life.
We don't want Rockbox to ever say "Out of memory". We want to know exactly what our worst-case memory situation is. And we want to make sure we can handle it. The heaviest music codec, the largets largest playlist, the most hairy id3 tags, the biggest plugins -- all at the same time.
This can in theory be accomplished in a system with dynamic memory allocation too, but it is very difficult and requires advanced runtime analysis and tools. With static allocation the compiler will simply refuse to compile if we use too much memory.
With dynamic memory allocation, you have a whole class of bugs related to mistakes in allocation, freeing and pointer management. Memory leaks, for example, can be very difficult and time consuming to track down and fix.
With static memory allocation, memory leaks are simply not possible. Of course we still use pointers, and occasionally write buggy pointer code. But it's a lot easier to debug.
Developers whose experience chiefly derives from Windows or Unix programming are not always used to thinking economically about memory use. Being forced to allocate every buffer statically in your code, to the maximum supported size, tends to have the effect of questioning and analysing the need for each buffer and byte.
r4 - 29 Nov 2010 - 16:35:31 - MichaelGiacomelliRevision r3 - 10 Apr 2008 - 18:28 - StephenEisenhauer
Revision r2 - 07 Nov 2007 - 07:55 - LinusNielsenFeltzing
Copyright © by the contributing authors.