?
Im Grunde genommen geht es noch einfacher:
#define lBufferMax = 1024 * 1024 * 128; /* maximum 128 MB */
void* pBuffer = malloc (lBufferMax);
size_t lBuffer = 0;
man wird erstaunt sein wenn man auf modernen OS die Zeit misst,
die fürs malloc (128 MB) benötigt werden: 0 Zeit!
Was ist los ?
pBuffer ist in diesem Moment nur eine Art versprechen, rein virtuell!
Das eigentliche Memory Paging erfolgt erst beim Zugriff und
nur soviel wie auch tatsächlich zugegriffen wird + prefetch in Pagesize (4K, ...).
Einen Nachteil hat das aber schon,
normalerweise muss der VMM, wenn er pBuffer != NULL liefert
für die 128MB entweder (relativ freies) echtes RAM oder eben SWAP in der Hinterhand haben (nicht auslagern, das ist erstmal nicht nötig!).
SWAP ist in diesem Fall soetwas wie die Goldreserven,
die, wenn der virtuell herausgegeben Speicher tatsächlich benutzt wird angegriffen werden.
Bei Linux kann man das Verhalten des VMM wunderbar einstellen,
so daß nocht nicht mal in der geforderten Größenodnung SWAP bereit stehen muss.
Zugegeben das erinnert an das Verhalten von Banken,
die ins 'Trudeln' kommen wenn die Leute ihr Geld wieder haben wollen.
Bei linux kommt dann der OOM Killer, der zweifelsfrei für freien Speicher sorgt,
indem Prozesse abschießt.
Tatsächlich haben wir für unsere Systeme sogenanntes overcommit eingestellt,
weil etliche Applikationen (z.B. Java) Faktoren mehr Speicher anfordern als
nacher benutzen.
mmap ist auch so ein Kandiat, der Speicher der gesamten Datei wird virtuell reserviert, tatsächlich gemappt wird nur das was auch benötigt wird (in 4K Schritten).
Tja wir konnten auf unseren Systemen nicht genügend SWAP für alle Eventualitäten auf dem Flash Massenspeicher reservieren,
darum eben overcommit + ein Programm was permanent den realen Speicherverbrauch,
Swap, ... ermittelt und visualisiert ...
Interesannt ist auch das Grenzverhalten bei overcommit.
Man erhält u.a. einen scheinbar gültigen pointer und
wenn man dann darauf zugreift einen segmentation fault
Gruß Frank
