4. Speicher aufräumen

Speicher aufräumen

  • F

    Hallo Leute!

    Einige, die mal stolzer Besitzer eines C64 waren werden sich noch an die sog. "Garbage Collection" (SYS 46374), mit der man den Speicher aufräumen konnte, erinnern. 😉

    Meine Frage ist: Kann man sowas auch bei Windows veranlassen (mit Messages, oder so), dass alle ungenutzten Objekte weggeschmissen werden?

    F98

    0
  • D

    Ich schätze nicht, dass das geht.
    Erstens sollte ein Programm selber dafür sorgen, dass der genutzte Speicher freigegeben wird und zweitens tut Windows das im Notfall selber.
    Dies hat den Grund, dsas man von Außen nicht einfach speicherbereiche überschreiben kann, die von einem Programm noch genutzt werden.

    0
  • M

    Ich glaube mich zu erinnern, daß Windows das auch auf Kommando kann... und zwar werden dann alle als Moveable gekennzeichneten Speicherblöcke neu geordnet. Das OS macht's wie gesagt von alleine um die Speicherfragmentierung zu korrigieren, aber irgendwie in der WinAPI ist dazu auch was zu finden, wie man das selbst auslöst.

    Mußt Dich mal via AllocMem vorantasten...

    Die interessante Frage ist, warum man das tun sollte oder vermeintlich zu tun glaubt.

    Kleine Sidenote: tatsächlich war die Speicherfragmentierung in den früheren Versionen auch ein Grund dafür, warum ein Server nicht beliebig lange durchgehalten hat... irgendwann war er so fragmentiert, daß Speicheranfragen immer NULL lieferten ab einer gewissen Größe. Ich denke NT4.0 Server bis SP4 hatte damit Probleme.

    0
  • C

    Hi,

    die Frage ist nur, wie funktionieren solche Speicherdefragmentiertools... indem ich Speicher verschiebe, werden ja alle Zeiger darauf ungültig und ich kann ja unmöglich den ganzen Speicher nach Zeigern durchsuchen und die ändern (mal davon abgesehen, dass dann unsinnige aber trotzdem erlaubte Sachen wie *(p + 1000) = 1234; wenn p ein long ist und 4000 Bytes weiter vorne auf den Speicher zeigt als die Variable wirklich allokiert wurde.
    Und Stackspeicher dürfte ja eigentlich nicht fragmentieren, der hat ja eine feste Größe (1MB per Standard).

    ChrisM

    0
  • J

    😉

    schonmal was von Virtual Memory gehört?

    0
  • C

    Hi,

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

    ChrisM

    0
  • F

    @Marc++us:

    Ich mach mich mal schlau. AllocMem ...

    0
  • ?

    SetProcessWorkingSetSize

    0
  • F
     

    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?

    0
  • F

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

    0
  • ?

    was für objekte meinst du? 🙄 🙄

    0
  • L

    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

    0
  • F

    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.

    0
  • M

    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. 😉

    0
  • J

    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

    0
Anmelden zum Antworten