Windows XP-Speicherverwaltung ohne Auslagerungsdatei - was sind die Konsequenzen? Fragmentierung zu haufen?

Question

Ich habe einen ziemlich schwer fassbaren Fehler untersucht, den wir in einer Anwendung auf einem Windows XP Embedded System sehen.

Wir haben den Fehler auf einen Zeiger eingegrenzt, der auf einen Speicherblock zeigen und stattdessen auf NULL zeigen sollte. Da der Speicher mit einem Aufruf von malloc (..) belegt ist, der nicht abhakt, sagt mein Instinkt, dass der malloc gescheitert ist und NULL zurückgegeben hat (obwohl wir auch nach anderen Möglichkeiten suchen, wie z Zeiger). Dies ist eine native C++ - Anwendung. Der Absturz war etwas verworrener, um dieser Ursache auf die Spur zu kommen, vor allem, weil wir nur post-mortal-Crash-Dumps hatten und sich der Fehler in einer Drittanbieter-Bibliothek manifestiert, für die wir keine Quelle in einem anderen Thread haben. Spaß mal :)

Meine Fragen konzentrieren sich auf die Speicher Erschöpfung Möglichkeit. Von Bedeutung ist, dass das XP Embedded-System, auf dem wir ausgeführt wurden, seine Auslagerungsdatei deaktiviert hat.

Also habe ich drei Fragen; es wäre toll, wenn jemand diese für mich klären könnte:

• In erster Linie, was sind die Auswirkungen der keine Auslagerungsdatei haben? Bedeutet das, dass wenn der Heap wächst, der neue Speicher vom Betriebssystem sofort gefunden und zugewiesen werden muss, auch wenn diese freien Blöcke nicht sofort verwendet werden? Ich habe einige anekdotische Erwähnungen davon gesehen, konnte aber nichts genaues darüber herausfinden, welche Auswirkungen die Auslagerungsdatei hat.

• Warum hat Microsoft beschlossen, den Low-Fragmentierungs-Heap nicht standardmäßig bis Windows Vista zu aktivieren? Besteht die Gefahr, dass der LFH für Ihren Prozess unter Windows XP aktiviert wird?

• Was ist der Unterschied in WinDbg zwischen "Externe Fragmentierung" und "Virtuelle Adressfragmentierung"?

WinDbg meldet die Haufen Statistiken über die betroffenen Haufen wie folgt:

Heap  Flags Reserv Commit Virt Free List UCR Virt Lock Fast 
        (k)  (k) (k)  (k) length  blocks cont. heap 
04770000 00001002 1621948 94844 1608284 102 6 8068 6  2 L 

    Virtual address fragmentation 94 % (8068 uncommited ranges) 

Answer 1

Im Gegensatz zu Linux, Windows eine Zuordnung eine Verpflichtung ist. Sie werden in der Lage sein, in den zugewiesenen Speicher zu schreiben. Leistung kann schrecklich sein, aber Windows benötigt keinen OOM Killer.

Wenn keine Auslagerungsdatei vorhanden ist, muss eine Zusage vom Arbeitsspeicher unterstützt werden. Und noch ungenutzter Speicher (wie er nur während der Programminitialisierung verwendet wird) verbraucht immer noch RAM, da er nicht ausgelagert werden kann. Es gibt also weniger RAM, um sich zu engagieren, aber ein viel größeres Bedürfnis.

Der LFH bricht Buggy-Programme, oder besser gesagt: Buggy-Programme können ihre Bugs in Anwesenheit von LFH zeigen. Microsoft ist extrem freundlich gegenüber defekten Programmen, und das LFH-Opt-In für XP ist ein typisches Beispiel für ihr entgegenkommendes Verhalten.