Freier Speicher in Delphiprogrammen ermitteln?

[Mavarik]

Hallo Zusammen...

Simples Programm:

Delphi-Quellcode:

Var
  f : array[0..100] of TByteDynArray;

procedure TForm49.Button2Click(Sender: TObject);
Var
   M : TMemoryStatus;
   i : Integer;
begin
  for i:=0 to 100 do
    begin
      Setlength(F[i],1024*1024*256);
      GlobalMemoryStatus(M);
      Memo1.Lines.add(Inttostr(M.dwTotalPhys div 1024)+' / '+Inttostr((M.dwAvailPhys) div 1024));
      Application.Processmessages;
    end;
end;

Ausgabe:
4194303 / 4194303
4194303 / 4194303
4194303 / 4104164
4194303 / 3840000
4194303 / 3580524

Peng - Out of Memory... Warum?

Wo ist der Trick?

Grüsse Mavarik

[himitsu]

Phys gibt den Speicher vom gesamten Windows an ... Was aber in deinem Programm, also im "virtuellen" Speicher, belegt/frei ist und was du demnach wirklich verwenden kannst, ist damit nicht ausgesagt!



Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

Wenn kein so großer zusammenhängender Block mehr da ist, dann *peng*.
Übeall fein verteilt liegt genutzter Arbeitsspeicher ( Heap? ), der/die Stacks, die gemappten Resourcen, und Programmcodes der EXE und DLLs rum.

Du könntest dir höchstens eine Memory-Map erstellen, wo du alle freien Stellen anzeigst.

PS: OK, bei der Größegibt dir FastMM einen Big-Block, welcher direkt von Windows geholt wird (VirtualAlloc), aber bei kleineren Speicherblöcken, geht das auf Medium- und Small-Blocks, welche immer in Gruppen bei Windows reserviert werden, wovon nicht alle verwendet sein müssen ... diese sind also laut Windows belegt, aber FastMM kann sie dennoch ans Programm weitergeben, weil sie eben nur "vorbestellt"/reserviert sind.


Tipp: GlobalMemoryStatusEx




Ach ja, und du schreibst nichts in diesen Speicher rein, das merkt Windows und verknüpft dieses nicht unbedingt sofort mit "echtem" Speicher ... erst wenn das wirklich verwendet wird.

Delphi-Quellcode:

type
  TIntArray = array[0..0] of Integer;
  PIntArray = ^TIntArray;
var
  i, i2 : Integer;
begin
  for i := 0 to 100 do
    begin
      Setlength(F[i], 1024*1024*256);
      for i2 := 1024*1024*256 div 1024 - 1 downto 0 do
        PIntArray(@F[i])[i2 * 1024 div SizeOf(Integer)] := 666;
      GlobalMemoryStatus(M);

(man könnte och mit FillChar und Co. jedes Byte einzeln füllen, aber Windows verwaltet den Speicher sowieso nicht byteweise ... 4 KB und 64 KB)

[Bernhard Geyer]

Zitat von Mavarik:

Peng - Out of Memory... Warum?

Weil in dem 32-Bit Adressraum deines Prozesses kein 256 MB-Großer zusammenhängender Bereich mehr frei ist.
Die ganzen DLLs die Windows noch zu deinem Prozess läd führen bei ungünstiger Implementierung dieser DLL noch schneller zu diesem PENG

Zitat von Mavarik:

Wo ist der Trick?

Kleinere Speicherblöcke anfordern oder als 64-Bit Anwendung kompilieren.

[Mavarik]

OK, Aber wie bekommen ich den Restspeicher in meinem 32 Bit Adressraum raus?

Mavarik

[himitsu]

physical (Windows) ... Virtual (Programm)

[info] hatte oben nochmal editiert


schön, daß es beim Editieren keine RedBox gibt

[Mavarik]

Mal abgesehen von der Exception die ich bei Deinem Code bekommen...

Was ist aus dem guten alten MemAvail/MaxAvail geworden?

Wie Frage ich den jetzt meinen Restspeicher ab?

Mavarik

[tgvoelker]

Zitat von Mavarik:

Peng - Out of Memory... Warum?

Weil Du den allokierten Speicher immer weiter erweiterst. Insofern stimmt

Zitat von himitsu:

Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

nicht.

Der Speicherblock, in dem Deine Struktur angelegt wird, ist eben nicht so groß, und wenn Du immer mehr Speicher allokierst, dann knallt es eben irgendwann.

Zu beachten ist ferner, daß Du nicht 4GB Datenspeicher allokieren kannst, standardmäßig nur 2GB, mit einem Bootswitch 3GB (http://support.microsoft.com/default...22120121120120 ==> in der Mitte)

Ich hatte mal ein Problem, daß ich große Grafikdaten im Speicher konvertieren mußte. Das Problem dabei war, daß ich oft nicht zusammenhängende Blöcke bekommen habe, die die Daten aufnehmen konnten (analog Deines Problemes).

Ich habe als Lösung eine Klasse geschrieben, die die segmentierten Blöcke allokiert und mit durchgängiger Adressierung angesprochen werden kann: http://www.tgvconsult.de/attachments...moryStream.zip

[Mavarik]

Zitat von tgvoelker:

Zu beachten ist ferner, daß Du nicht 4GB Datenspeicher allokieren kannst, standardmäßig nur 2GB, mit einem Bootswitch 3GB (http://support.microsoft.com/default...22120121120120 ==> in der Mitte)

Ich hatte mal ein Problem, daß ich große Grafikdaten im Speicher konvertieren mußte. Das Problem dabei war, daß ich oft nicht zusammenhängende Blöcke bekommen habe, die die Daten aufnehmen konnten (analog Deines Problemes).

Ich habe als Lösung eine Klasse geschrieben, die die segmentierten Blöcke allokiert und mit durchgängiger Adressierung angesprochen werden kann: http://www.tgvconsult.de/attachments...moryStream.zip

Danke für Deine Antwort... Aber darum geht es garnicht...

Ich will garnicht auf 4GB oder meine 8GB RAM zugreifen... Ich will lediglich vor einer Speicherreservierung abfragen können ob der Speicher + eine "not-Reserve" noch frei ist... Und zwar innerhalb der 32BIT Kachel die ich vom Windows erhalten habe... Bei XP oder Win32 stellt sich die Frage nicht, da "NIE" genug Speicher da ist... aber ich erhalte ja unter Win 7 64 Bit die Meldung 3,8 GB Frei aber die Meldung Out of Memory...

Mavarik

[himitsu]

[QUOTE=tgvoelker;1174445]

Zitat von Mavarik:

Insofern stimmt

Zitat von himitsu:

Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

nicht.

Nicht?

Setlength(..., 1024*1024*256); fordert für das dynamische Array 268435456 Felder an, was durch SizeOf(Byte) der einzelnen Felder natürlich den 256 MB entspricht und dazu dann noch 2 Integer für die Verwaltung des Arrays (Größe und Referenzzählung).



Button1 = Deines
Button2 = Sucht die größten Speicherblöcke

[add]
Mit NativeUInt(F[i]) könntest du dir noch die Speicheradressen dieser Blöcke ausgeben lassen.

Ach ja, am Ende bleibt noch etwas im Virtual übrig ... das sind vermutlich RESERVED-Blocks, welche frei sind, aber nicht "nochmal" reserviert (MEM_COMMIT) werden können. (siehe VirtualAlloc)

[Mavarik]

Hmm

Interessant...

Ich verstehe zwar nicht so ganz was Du da machst...

Aber M.dwAvailVirtual scheint der richtige Wert zu sein...

Abgesehen davon, das das Programm nicht durchläuft und mit einer Exception abstürtzt...

Mavarik