Large-Address-Aware flag

[youuu]

Hi, wie der Title schon sagt, wie kann ich in Delphi die Large-Address-Aware Flag setzen`?

[Luckie]

Wozu musst du das setzen? Mir ist bisher kein Problem unter gekommen, wo das nötig gewesen wäre.

[youuu]

Ich habe ein Programm, welches sehr viele Daten zur gleichen Zeit verarbeitet und im Arbeitsspeicher speichert, jedoch kommt es ab und zu vor, das der Memory Speicher voll ist. Besitze WIn7 64 Bit.

[Luckie]

Gibt es den Flag bei 64-Bit überhaupt noch? Und ist es ein 64-Bit Programm? Wie sieht denn deine Speicherverwaltung aus? Ich würde nicht mehr benötigte Objekte wieder löschen.

[youuu]

Nein ist lediglich eine 32 Bit Anwendung oder kann Delphi schon 64 Bit?

[Luckie]

Die neuste Version kann es.

Also ich würde mir noch mal über das Konzept Gedanken machen. Müssen denn wirklich immer alle Daten im Arbeitsspeicher sein? Hinzukommt, dass das Flag dein Problem nicht unbedingt lösen muss. Wenn der Adressraum deines Prozesses zu sehr fragmentiert ist, kann es schon vorkommen, dass für bestimmte Speicheranforderungen nicht mehr genug aneinander hängende Adressen zu Verfügung stehen.

[youuu]

Ok, werde mal schauen was ich da noch verbessern kann.

Welche Version ist das und kann ich damit meine aktuelle 32Bit einfach in 64Bit umwandeln, ohne neu zu schreiben?

Edit: seh grad Delphi XE2, kann auch Mac?

[daywalker9]

Ja, XE2 kann für Mac und Windows Executables erzeugen, iOS geht nur über einen Umweg mit XCode und FreePascal Compiler.

Btw was Du suchst sind die PE Flags

[Luckie]

Ich bin aber immer noch der Meinung, dass das nicht die Lösung sein kann. Und wer stellt die Option denn in der Windows Boot.ini ein? Das Setup?

[himitsu]

Jupp, es muß erstmal im Windows aktiviert sein, dann muß das PE-Flag gesetzt sein und alle Programmteile in deinem Programm müssen dieses unterstützen (sonst passieren unerwartete Dinge).

Wenn unbedingt viele daten verwaltet werden müssen, dann nimm doch eine MMF, diese kann größer sein, als der virtuelle Arbeitsspeicher deines Programms, da man davon ja immer nur die aktuell benötigten Teile in seinen virtuellen Arbetsspeicher mappen braucht.

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1139280)

Jupp, es muß erstmal im Windows aktiviert sein, dann muß das PE-Flag gesetzt sein und alle Programmteile in deinem Programm müssen dieses unterstützen (sonst passieren unerwartete Dinge).

Nicht nur dann. Das kann auch schon so passieren, weil Windows dann auch an seine Grenzen kommt. Für Windows bleiben dann nämlich nur 1 GB Adressen im Adressraum übrig. Und das ist arg knapp.

[himitsu]

Alle Programme zusammen können mehr als die 2 GB belegen.

Das Flag sagt ja nur, daß der einzelne Prozess nicht mehr als 2 virtuelle GB bekommt.
Aber auch mit nur 2 GB können schon 2 solcher Programme alles überfüllen. Mit LAA würde das nur schon ein einzelnes Programm schaffen.

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1139282)

Alle Programme zusammen können mehr als die 2 GB belegen.

Das Flag sagt ja nur, daß der einzelne Prozess nicht mehr als 2 virtuelle GB bekommt.
Aber auch mit nur 2 GB können schon 2 solcher Programme alles überfüllen.

Afaik geht es darum, das Windows im virtuellen Adressraum des Programm (eines jeden Programms) zu wenig Platz hat. Es geht also nicht direkt um den physikalischen Speicher.

[Luckie]

Normalerweise hat jeder Prozess unter 32-Bit einen Adressraum von 4GB, wo von 2GB für Windows reserviert werden. Dort blendet Windows die Adressen der System DLLs ein. Wird nun dieses Flag gesetzt, hat ein Prozess von diesen 4GB 3GB zur Verfügung und Windows nur noch 1GB. Und mit 1GB stößt Windows so ziemlich an seine Grenzen.

[himitsu]

Das hast du jetzt falsch verstanden.

Von dem virtuellen Adressraum der Anwendungen nimmt Windows nix für seine Verwaltungsaufgaben, sowie für die Cache.

Windows 32 hat seinen 2/4 GB adressierbaren Speicher ... mit PAE (Physical Address Extension) auch mehr.
Dazu dann noch die Pagefile.

Die reservierten/genutzten Teile des virtuellen Speichers jeder Anwendung wird dabei in den physischen Speicher gemäppt,
wobei es sich standardmäßig (vorwigend) von den hohen physikalischen Speicherbereichen etwas für sich und die Treiber nutzt.

Mit LAA kann man jetzt erstmal nur sagen, welchen virtuellen Bereich die Anwendung nutzen kann/darf,
aber wo dieses dann im physischen Speicher (RAM/Pagefile) liegt, ist dem Programm selber vollkommen egal.
Die einzelnen virtuellen Speicherblöcke können sogar wild verteilt im physischen RAM und teilweise auch in der Pagefile liegen.

Einige Teile existieren sogar nichmal direkt im RAM. Viele der MMFs z.B., worüber auch die Binaries der EXEn/DLLs im virtuellen Arbeitsspeicher liegen.
Ist nicht genug Platz im RAM, dann landen große (unveränderte) Teile nicht in der Pagefile ... wäre ja unnötig, da die ja direkt in der EXE-Datei zu finden sind, von wo man sie wieder laden kann, sobald das Programm sie benötigt.

[Luckie]

Bitte nachlesen: http://msdn.microsoft.com/de-de/library/ms189334.aspx
Und wirf auch mal einen Blick auf die Grafik. Sie zeigt genau das, was ich erklärt habe.

Zitat:

Alle Betriebssystemversionen ab Windows 2000 Server, einschließlich Windows Server 2003, besitzen einen Parameter in Boot.ini, mit dem Anwendungen Zugriff auf 3 GB Prozessadressraum gewährt wird. Der Adressraum für den Kernelmodus wird dann auf 1 GB beschränkt.

Wo, sich die Daten dann letztendlich befinden, drüber habe ich gar keine Aussage getroffen. Ich kenne ein Windows mit 512MB, dass da der Adressraum auf die Festplatte ausglegaret werden muss ist klar.

[himitsu]

Deswegen muß man es doch auch an 2 Stellen aktivieren, wenn man es nutzen will.

Einmal für Windows (wobei z.B. die WindowsFileCache nicht nur auf den höheren Speicherbereich beschränkt ist)
und dann noch das Flag im jeweiligen EXE-Header.

Das EXE-Flag hat aber keine Wirkung auf die "reale" Speicherverwaltung des Windows,
sondern nur auf die Virtuelle der Anwendung.

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1139558)

Deswegen muß man es doch auch an 2 Stellen aktivieren, wenn man es nutzen will.

Ich habe nichts anderes behauptet.

Zitat:

Einmal für Windows (wobei z.B. die WindowsFileCache nicht nur auf den höheren Speicherbereich beschränkt ist)

Wie kommst du denn jetzt auf den Windows File Cache?

Zitat:

Das EXE-Flag hat aber keine Wirkung auf die "reale" Speicherverwaltung des Windows,
sondern nur auf die Virtuelle der Anwendung.

Auch da habe ich nichts anderes behauptet.

[Bernhard Geyer]

Zitat:

Zitat von Luckie (Beitrag 1139539)

Wird nun dieses Flag gesetzt, hat ein Prozess von diesen 4GB 3GB zur Verfügung und Windows nur noch 1GB. Und mit 1GB stößt Windows so ziemlich an seine Grenzen.

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden? Es gibt genügend Teile von Windows die den Anwendungs-Prozessraum nicht tangieren. Bei 1GB physikalischen RAM gebe ich dir echt mit den Grenzen wenn es um Vista oder Win7 geht.

Ich gebe dir aber recht das man eigentlich in vielen Fällen einen Design-Fehler im Programm hat wenn 2 GB an virtuellen RAM für die nicht reichen würden. Außer natürlich man entwickelt sowas wie ein DBMS ...

Aber mir hat schon mal geholfen bis zur Behebung eines Implementierungsmangels die Anwendung mal mit dem 3GB-Schalter kompilieren zukönnen :-). Und da mittlerweile 64-Bit Windows der Standard ist braucht der Anwender auch nix konfigurien. Win32-Prozesse haben unter Win64 eigentlich immer 3GB zur "eigenen" Verfügung.

[Luckie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139584)

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden?

Keine Ahnung, aber laut Jeffrey Richter, sind angeblich schon 2GB unter Windows 200 recht knapp bemessen. Eventuell hat sich das ab Windows XP geändert.

[himitsu]

Windows 7 Starter hat eine sehr nette Einschränkung und kann maximal 1 GB an physischem RAM ansprechen (Cracks, Hacks und Co. ausgeschlossen)

so viel zum eng

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1139596)

Windows 7 Starter hat eine sehr nette Einschränkung und kann maximal 1 GB an physischem RAM ansprechen (Cracks, Hacks und Co. ausgeschlossen)

Imho verwechselst du immer noch den Mangel an Adressen im Adressraum mit Mangel an echt verfügbaren Speicher.

Natürlich kommt Windows ins Swappen, wenn zu wenig physischer Speicher da ist (oder es nur 1GB davon nutzt).
Wenn aber nicht genug Adressen da sind, kann es andere Probleme geben als nur ein ständig mit der Ein-/Auslagerung beschäftigter Rechner.

Du sagst quasi, das du nicht genug Zimmer hast, um 200 Leute gleichzeitig bei dir wohnen zu lassen. Kein Problem, immer wenn jemand ein Zimmer braucht, schmeißt du einen anderen raus.
Windows hat aber ein anderes Problem, wenn du ihm nur ein Gigabyte Adressraum zugestehst: es kennt nicht genug Namen, um all die Leute unterscheiden zu können.

[CCRDude]

Zitat:

Zitat von Luckie (Beitrag 1139553)

Bitte nachlesen: http://msdn.microsoft.com/de-de/library/ms189334.aspx
Und wirf auch mal einen Blick auf die Grafik. Sie zeigt genau das, was ich erklärt habe.

Zitat:

Alle Betriebssystemversionen ab Windows 2000 Server, einschließlich Windows Server 2003, besitzen einen Parameter in Boot.ini, mit dem Anwendungen Zugriff auf 3 GB Prozessadressraum gewährt wird. Der Adressraum für den Kernelmodus wird dann auf 1 GB beschränkt.

Ich habe hier mal den wichtigen und von Dir vermutlich mißverstandenen Punkt unterstrichen.

Der "abgetrennte" Bereich ist Kernel-Mode-Speicher! Das hat erstmal nichts direkt mit "Windows" oder "System-DLLs" zu tun. Die allermeisten Windows-DLLs laufen nicht im Kernel, sondern im user mode. Treiber etwa brauchen Kernel-Speicher. Graphik in der Wikipedia dazu.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139584)

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden?

Da Du mit 32-Bit-Prozess vermutlich eine normale Anwendung meinst - darein lädt man höchstens normale Win32-Subsystem-DLLs, und ist damit zu 100% im Usermode. Natürlich greifen die letztendlich auch wieder auf untere Schichten zu, so daß irgendwo da auch Kernelspeicher verwendet wird. Aber das ist eher nutzdatenabhängig und nicht von der Größe der DLLs.

"Glücklicherweise" arbeitet Windows nur mit Ring 0 (kernel mode) und 3 (user mode), ich will gar nicht wissen wieviel Verwechslungsmöglichkeiten es gäbe, wenn 1 und 2 auch noch genutzt wären :-D

[Luckie]

Gut mit den System-DLls war ich dann nicht ganz präzise. Aber wenn der Kernel nicht zu Windows gehört, zu was gehört er denn dann? ;)

[Bernhard Geyer]

Zitat:

Zitat von CCRDude (Beitrag 1139627)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139584)

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden?

Da Du mit 32-Bit-Prozess vermutlich eine normale Anwendung meinst - darein lädt man höchstens normale Win32-Subsystem-DLLs, und ist damit zu 100% im Usermode. Natürlich greifen die letztendlich auch wieder auf untere Schichten zu, so daß irgendwo da auch Kernelspeicher verwendet wird. Aber das ist eher nutzdatenabhängig und nicht von der Größe der DLLs.

"Glücklicherweise" arbeitet Windows nur mit Ring 0 (kernel mode) und 3 (user mode), ich will gar nicht wissen wieviel Verwechslungsmöglichkeiten es gäbe, wenn 1 und 2 auch noch genutzt wären :-D

Die Ring0-Anwendungen werden auch mit der entsprechenden Option mehr als 1GB Ram im eigenen Prozess verwenden können. Oder kennst du einen Ring0-Prozess/Dienst/... oder was auch immer der auch nur annähernd 1GB an Ram benötigen würde?

[Bernhard Geyer]

Zitat:

Zitat von Luckie (Beitrag 1139636)

Gut mit den System-DLls war ich dann nicht ganz präzise. Aber wenn der Kernel nicht zu Windows gehört, zu was gehört er denn dann? ;)

Der Kernel wird aber nicht nur aus einem Prozess bestehen der mit dieser Option nur 1 GB verwenden darf. Es sind wohl eher viele kleine Apps die nur in Ausnahmefall mehr als 100 MB Ram benötigen (Ganz im Gegensatz zu den "fetten" Firefox, Outlook, Delphi, ...)

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1139596)

Windows 7 Starter hat eine sehr nette Einschränkung und kann maximal 1 GB an physischem RAM ansprechen (Cracks, Hacks und Co. ausgeschlossen)

woher hast du diese Information? Mein Vater hat ein Netbook mit Windows 7 Starter. Und er hat es gerade auf 2GB aufgerüstet und Windows zeigt auch 2GB Arbeitsspeicher an, kann es also verarbeiten.

[BUG]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139644)

Der Kernel wird aber nicht nur aus einem Prozess bestehen der mit dieser Option nur 1 GB verwenden darf. Es sind wohl eher viele kleine Apps die nur in Ausnahmefall mehr als 100 MB Ram benötigen

Für viele Sache gibt keine eigenen Prozesse. Deine "Apps" samt Daten müssen im Zweifelsfall alle in jeden Adressraum eingeblendet werden, um eben adressierbar zu sein, falls der Prozess (absichtlich oder nicht) in den Kern wechselt.

[Stevie]

Zitat:

Zitat von Luckie (Beitrag 1139856)

Zitat:

Zitat von himitsu (Beitrag 1139596)

Windows 7 Starter hat eine sehr nette Einschränkung und kann maximal 1 GB an physischem RAM ansprechen (Cracks, Hacks und Co. ausgeschlossen)

woher hast du diese Information? Mein Vater hat ein Netbook mit Windows 7 Starter. Und er hat es gerade auf 2GB aufgerüstet und Windows zeigt auch 2GB Arbeitsspeicher an, kann es also verarbeiten.

Ausgedacht hat er sich das, Limit der Starter sind 2 GB

[Luckie]

Also ist das Limit 2GB und nicht eins.

[CCRDude]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139643)

Die Ring0-Anwendungen werden auch mit der entsprechenden Option mehr als 1GB Ram im eigenen Prozess verwenden können. Oder kennst du einen Ring0-Prozess/Dienst/... oder was auch immer der auch nur annähernd 1GB an Ram benötigen würde?

Ich bin mir jetzt unsicher, was das mit dem von Dir zitiertem Text zu tun hat, aber: bei dieser Einschränkung geht es eigentlich immer nur um den Adreßraum zu einem fixen Zeitpunkt.

Wenn ich mal ganz weit zurückblicke: schon zu Dos-Zeiten waren solche Einschränkungen relativ. Paging sei dank. EMS & XMS mal als Stichpunkte (ich glaube EMS war das bessere Beispiel für paging? Ist schon so lange her ;) ). Windows selber unterstützt ja prinzipiell systemweit schon mehr dank Auslagerungsdateien. AWE ist eine Technik, die auch 32-Bit-Prozessen mehr Speicher durch Paging erlaubt.

Ob AWE selber auch ein Pendant auf Kernel-Ebene hat, weiß ich gerade leider nicht.

Um auf die Frage einzugehen, was in Ring0 auch nur anhähernd 1 GB benötigen würde - ich würde mal vermuten, Anwendungen, die I/O mit riesigen Datenblöcken implementieren. Sowas zu planen ist natürlich Blödsinn, aber vielleicht in vom Programmierer unvorhergesehen Situationen (I/O-Code, der, weil er auf Kleindateien ausgelegt ist, nicht blockweise arbeitet, dann aber auf ein ISO-Image losgelassen wird). Wenn Texturen in die Grafikkarte kopiert werden, sind die sicher auch nicht gerade klein,.