Re: Fragmenting memory

To expand on Florent's post:

Memory managers exist because calling to the OS for every little memory
request would take to long. So the memory manager grabs a chunk of memory at
a time and then slices it up as needed. It becomes fragmented when it can't
or doesn't support merging the slices back together.

Simple example:

for x := 0 to 999 do
ObjArr[x] := TMyObject.Create;

for x := 0 to 999 do
FreeAndNil(ObjArr[x]);

This just made 1000 objects, sliced whatever memory your app requested from
the OS into a 1000 slices and freed the objects, but you're left with 1000
slices of whatever size your objects were. After when you allocate something
bigger that TMyObject the MM will have to request more memory from the OS
because all of its current slices are too small, and now your memory is
fragmented, it was there but wasn't usable. Unlike a filesytem that supports
spliting your file across the drive where there's room, memory allocations
have to exist as one continuous space in memory.

Replacement MM's all tend to deal with this problem and use a more
complicated internal structure to help prevent fragmentation. There's
several ways to do this, but the fastest seems to be using various pools of
memory that are dedicated to certain sized memory requests, so now instead
of having one big list to manage there's several smaller lists each with
their own special purpose.

DD


.

Relevant Pages