Speicher aufräumen

ChrisM

Hi,

jo, aber die Blöcke fragmentieren doch nicht, oder?

ChrisM

F98

@Marc++us:

Ich mach mich mal schlau. AllocMem ...

SetProcessWorkingSetSize

F98

BOOL SetProcessWorkingSetSize(
    HANDLE hProcess,	// open handle to the process of interest
    DWORD dwMinimumWorkingSetSize,	// specifies minimum working set size
    DWORD dwMaximumWorkingSetSize 	// specifies maximum working set size
)

The working set of the specified process can be emptied by specifying the value 0xffffffff for both the minimum and maximum working set sizes.

Bedeutet das jetzt, wenn ich z.B.

SetProcessWorkingSetSize(hProcess, 0xffffffff, 0xffffffff);

ausführe, dann werden alle zum Process gehörenden Objekte gekillt?

F98

Toll dass ich erst die Suchfunktion bemühen mußte um rauszufinden, wohin mein Beitrag verschoben wurde ...

was für objekte meinst du?

Lui

Schön dass sich noch jemand an den 64'er erinnert

Ich versuchs mal kurz:
Eine vom OS unterstützte "garbage collection" gibt es nicht
und kann es auch nicht geben da das System nicht wissen kann
welche Variablen oder meinetwegen auch Objecte noch vom jeweiligen
Prozess benötigt werden (zum 64'er gleich mehr).
Alle auf den Intel aufbauendeN 32bit Betriebssysteme verwalten
den Speicher in 4kb großen Blöcken die i.A. an beliebige Stellen
des physikalischen Speichers oder auf Festplatte etc. verschoben
werden können.
Anwendungsprogramme 'sehen' die einzelnen Blöcke als durchgehenden
Adressraum
Das was als speicherdefragmentieren bekannt ist ist nix weiteres
als das der 'Defragmetierer' versucht möglichst allen physikalisch
vorhanden Speicher für sich zu reservieren um damit das OS dazu zu
bringen die anderen Prozesse auf Festplatte auzulagern (war auch
vor ein paar Tagen Thema in einem Thread)achja gibt danach den Speicher
natürlich wieder frei
Mit dem 'SetProcessWorkingSetSize' Beispiel -aufgerufen für jeden Prozess-
wird das gleiche erreicht. (nein es werden keine 'Objekte' gekillt nur
ausgelagert)

Aber wirklich tot ist die "Garbage collection" trotzdem nicht:
Es gibt genügend Programierumgebungen (wie es das 64'er basic
war) die sich darum bemühen den angeforderten Speicher effizient
zu benutzen(generell wohl alle interpreter Sprachen, afaik Java und
Klassen in c++ - implementierungs abhängig)

Hoffe das war einigermaßen verständlich (sonderfälle wie höhere
Privilegstufen, Real-mode und gemeinsame Adressräume hab ich mal
aussen vor gelassen)

Ich weis ja nicht wie gut du dich mit dem 64'er auskanntest, aber
ich hätt da noch 'ne nette zusammenfassung:
OS - 64'er: e000-ffff / win / linux etc. : keine garbage collection
Interpreter - 64'er:a000-bfff / jscript / perl etc. : garbage collection

F98

Ich bin nur deswegen darauf gekommen, weil bei Java so eine GC existiert. Ich nahm also an, dass das betriebsystemseitig erledigt wird, und nicht von der Laufzeitumgebung.

Marc++us

Hm... das ist aber genau genommen auch richtig, denn die Java VM ist eine Art BETRIEBSSYSTEM! Demnach ist Deine Erwartung durchaus richtig... aber Du hast im falschen Betriebssystem gesucht.

Jester

ChrisM schrieb:

jo, aber die Blöcke fragmentieren doch nicht, oder?

Sollten sie eigentlich nicht, tun sie aber doch.
Es gibt nämlich nicht nur die gewöhnlichen 4KB-Pages, sondern auch sogenannte Superpages, die sind 4MB groß und müssen auch so am Stück im physischen Speicher liegen. Und dafür lohnt sich das defragmentieren.

MfG Jester