Memory management is one of the most fundamental areas of computer programming. In many scripting languages, you don’t have to worry about how memory is managed, but that doesn’t make memory management any less important. Knowing the abilities and limitations of your memory manager is critical for effective programming. Get an overview of the memory management techniques that are available to Linux programmers, focusing on the C language but applicable to other languages as well.
Inside Memory Management
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
An excellent overview, mentions all the issues.
This is the biggest sticking point for me in programming and why I’ve always sucked at it. I just can’t seem to get it right, which causes most of my programs to puke all over with segmentation faults and memory leaks….
– Kelson
No, I don’t write code for Cisco. I build networks, luckily I’m much better at that than writing code.
“which causes most of my programs to puke all over with segmentation faults and memory leaks”
Most programmers have problems with allocating and freeing memory because they insist on using malloc and free
as raw routines without wrapping them in any type of abstraction. I keep seeing code like:
/* make a buffer*/
void *buffer;
buffer=malloc(1000);
/*use buffer*/
((char *)buffer)[n]=yada;
….
/* dump buffer*/
free(buffer);
This is pretty stupid use of memory. A.) There’s no bounds checking. B.)There’s no limiting C.) there’s no fail safe
testing to see if memory is a zombied allocation.
There’s no assured deallocation by having local allocation stack tracing/testing…
That’s what structured types are for. Make memory types
and a memory stack. Make routines to check what local allocations can be dumped. Don’t use global variables,
this forces allocations to stay local. Deallocate based on the call stack.
Most importatly of all….relax….
🙂
One slight little tiny error :
Primitive garbage collectors needs to stop the system ( usually a VM ) and garbage-collect the whole memory.
A “incremental” garbage collector instead does the full garbage collection in several calls to prevent stopping the VM for a long time. The VM can modify the currently mark/sweeped memory and these alteration must be told back to the GC ( for example with tricolor marking )
A “generational” garbage collector does trace the age of objets to do only partial garbage collection as an empirical rule states that in most programming languages most objets either die very soon after their creation or are kept for the whole program execution time. Here also the links between generations made by the VM must be traced. Recent objets are scanned for garbage collection more often than older ones.
These are orthogonal issues. A GC can be both “incremental” and “generational”. These topics are related because usually the techniques needed to trace the alteration of the marking process by the VM during a partial garbage collection are the same that allows tracing of intergenerational links.
They link to mmalloc from gdb… but unfortantly it’s no longer used in gdb and I have yet to get it working… looking at the code it appears that the concept is flawed which explains why it wouldnt work. However, the code dates back to 1992 and was only recently depreciated… so it must have worked at one point. I’ve got some beta quality code which recreates the functionality of mmalloc but I need to do more tests. mmap is far from an idea way of creating a malloc interface with a backing store… but i’ve yet to find an easier way to do it.