Stack und Heap

[unknown]

Hallo,

Und du bekommst meistens mehr Speicher, als du eigentlich anforderst. Windows teilt beispielsweise Speicher nur in Portionen von 4kB zu; wenn die Anwendung also 24 Bytes anfordert, bekommt sie 4kB. Das ist aber systemabhängig.
Aber doch nur, wenn eine neue Page angefordert wird. In diese legt der Heapmanager dann solange weitere Variablen rein, bis die Page voll ist.

kann es sein, dass du hier die Speicherverwaltung des OS und die der C-Runtime vermischt hast?

Ja, diese sind ja auch vermischt. Bzw. bist eigentlich du über die CRT hinausgegangen und hast die Speicherverwaltung des Systems ins Spiel gebracht.
Für mich hat sich das angehört(man hätte es so deuten können), als wolltest du sagen, daß unter Windows für jede dynamisch erzeugte Variable immer ein vielfaches der Pagesize an Speicher reserviert wird.
Das ist aber nicht so.

AFAIK arbeitet die C/C++-Runtime mit malloc() oder dem new-Operator so, wie du beschrieben hast: Sie fordert einen großen Block Speicher vom OS an, und gibt bei jedem malloc()-Aufruf kleine Häppchen davon an das Programm. Divide et impera. ;-)

Das kommt auf die CRT und das BS an. Wenn wir über Windows reden, dort existiert ein »» Heapmanagement im Kernel. Inwieweit die CRT diese nutzt oder nicht, ist deren Implementationsdetail.
Im MS-Compiler wurde bis CRT8.0 für Blöcke bis einschliesslich 480 Byte eine eigene Heapverwaltung in der CRT implementiert und erst für grössere der Windows-Heapmanager verwendet.

Wenn ich von Windows einen Speicherblock mit GlobalAlloc() anfordere, ...

GlobalAlloc nutzt auch einen Windows Heap. Nur einen anderen als die CRT. Eine Page reserviert man mit VirtualAlloc, auch der Windows-Heapmanager.

Das eigentliche Problem unter Windows ist, dass der Heapmanager diesen Speicher für Blöcke kleiner 512k nicht wieder frei gibt, sonder nur decommittet.

Hö?

Der Windows-Heapmanager ruft nie VirtualFree mit MEM_RELEASE für diese Bereiche auf (für einen Low Fragmentation Heap).

einer der Vorteile der virtuellen Speicherverwaltung (nicht zu verwechseln mit der Swapdatei!) ist doch, dass man über die Descriptortabellen die 4kB-Kacheln mit gleichbleibenden virtuellen Adressen lustig im physikalischen Adressraum hin- und herschieben kann. So kann man Fragmentierung von vornherein vermeiden, bzw. sie ist aus Applikationssicht nicht erkennbar.

Das verstehe ich nicht ganz, ich rede von der Fragmentierung innerhalb der Heaps.
2K anlegen => 4K anlegen => 2K anlegen => 4K anlegen => 2K löschen => die anderen 2K löschen
=> 4K anlegen