Warum verwendet man Memory Pages?
Hallo!
Warum ist der physische RAM in Pages einer bestimmten Größe eingeteilt?
Warum reserviert man für ein bestimmtes Programm nicht einfach 5 MB anstelle von n Pages?
Lg
4 Antworten
Im wesentlichen fehlende Dynamik. Wenn ich den physischen Speicher in Kacheln zersäbel, dann habe ich eien 'überschaubare' Anzahl an solchen Kacheln.
Ich kann die gleiche Kachel mehreren Prozessen in Ihrem jeweiligen Adresskontext zur Verfügung stellen. Ich kann Kacheln auslagern, die nicht benötigt werden.
Naja, üblicherweise haben KAcheln 4KB oder mehr.
2 Prozesse benutzen die gleiche DLL, ich lade die DLL an die physikalische Speicheradresse X. Prozess A bekommt sie in seinem virtuellen Adressraum an Position Y zur Verfügugn gestellt, Prozess B and Position Z. Dadurch, daß ich die Page in mehrere Prozesse an beliebige Stellen in Ihrem Adressraum 'mappen' kann, habe ich eine hohe Flexibilität.
Ja, sollte die Page ausgelagert sein, dann gibt es einen Pagefault und die Seite muß in den Speicher geladen werden. Andererseits kann ich so einem Prozess aber n Pages zur Verfügung stellen, sodaß n*Pagesize>c*PhysicalRAM. (So funktioniert im Endeffekt virtueller Speicher).
Es gibt diverse Strategien zur Seitenersetzung, aber das ist wieder ein eigener Themenkomplex.
Dank Paging kann ich übrigens auch Techniken wie Samepage-Merging umsetzen.
Ferner, wenn mein Allocator COWed, dann kann er eine Zeropage beliebig oft in den virtuellen Adressraum des Prozzesses kopieren, erst beim Befüllen muß wirklich Speicher belegt werden.
----
Nochmal zur Auslagerung. 4KB Pages korrespondieren mit 4K Sektoren der HDD oder eben 8 512 Byte Sektoren. Eine Page lässt sich also recht schnell lesen. Überschreitet mein Workingset aber den vorhandenen Speicher, kommt es zum Thrashing.
Was ist wenn man 100 Byte Speicher braucht? Dann muss man eine ganze Page mit 4KB reservieren? Weil es keine kleinere Speichereinheit gibt?
Angenommen eine Dll braucht 0x3000 Bytes für Header, Text und Daten. Dann muss die MMU das durch die Pagesize dividieren und demnach habe ich dann sagen wir 5 Pages wo meine Dll zugeordnet ist und eine halbe wird bloß reserviert?
Und wenn ich die Dll mit einer weiteren Exe lade, dann wird das im virtuellen Specherbereich bloß "angezeigt" aber ist eigentlich in der Page 1-6?
Und auch wenn mir der Debugger einen Adressbereich von 0 bis 7FFFFFF anzeigt ist nur ein kleiner Teil davon genutzt für Code und Daten der Module und der befindet sich wiederum in den Pages verteilt?
Also kann sich ist virtueller Speicher eine Art Pointer auf tatsächlichen Speicher auf HDD oder RAM? Und wenn mein Programm die Adresse "0x401000" im virtuellen RAM aufruft, dann leitet die CPU das an eine der Pages weiter wo sich dass dann tatsächlich befindet? Dann braucht es ja wieder die Pagenummer und den Offset, weil das Programm wird ja irgendwie zerhackt damit es sich in den Pages ausgeht?
Ja richtig, das gleiche hast Du auch bei Dateien auf der Festplatte, Dateisysteme arbeiten in Blöcken. Im Zweifelsfall wird 1 Page allokiert, auch wenn ich nur 1 Byte benötige, weitere Allokationen können dann natürlich in die gleiche Page, bis sie überläuft.
Das nächste verstehe ich nicht - Die DLL wird beim Laden über die notwendige Anzahl an Pages verteilt, aber linear in den virtuellen Adessraum gemappt. Die MMU hat mit der Allokation erstmal primär nichts zu tun, sie unterstützt bei der Adressabbildung, sorgt also unter anderem dafür, daß das Ganze linearisiert wird.
Ja, natürlich gilt das gleiche für das Prozessimage.
https://de.wikipedia.org/wiki/Virtuelle_Speicherverwaltung
Erklärt das doch eigentlich recht schön.
Warum funktioniert das alles eigentlich so gut dass die PCs so lange laufen und da nie irgendein Bus oder ein Chip mal falsch arbeitet frage ich mich gerade.
Hat Windows ueberhaupt selbst Einsicht in die realen Adressen oder ist das reine Hardwaresache und Windows kann bestenfalls über Rueckmeldungen Einfluss nehmen?
Ehm, Ja, natürlich hat der Ring0 direkt physischen Zugriff auf den Speicher, die Speicherverwaltung von Windows kooperiert mit der MMU, indem sie beim Kontextwechsel die nötigen Informationen des Prozesses bereitstellt, damit die MMU die Mappings kennt. (Ich vereinfache hier ein wenig).
Es gab Zeiten, da gehörten Bluescreens (quasi) zur Tagesordnung, es ist ja nicht so, daß das alles über Nacht fertig und gut funktionierend vom Himmel gefallen ist :-D.
Und daß das gesamte Feld auch nicht ganz so einfach ist, haben ja Meltdown, Spectre und Friends gezeigt.
1.) Heißt mappen eigentlich bloß Speicherpages in andere Pages kopieren oder?
2.) Hat virtual Memory abgesehen vom auslagern auf die Festplatte auch noch Vorteile?
3.) Was passiert wenn ein Programm abstürzt? Dann weiß Windows das Programm verwendetr 3 Pages und die 3 werden dann einfach freigegeben?
4.) Was ist wenn man mit malloc neuen Speicher reserviert? Wird dann eine Page bevorzugt wo noch wenig drauf ist oder einfach irgendwo das reserviert und ggf. neue Pages reserviert obwohl noch auf den eigenen Platz wäre?
5.) Und kann ein Prozess dann quasi nur auf Pages schreiben oder lesen, die diesem zugeteilt wurde, ohne jetzt WriteMemory oder so zu verwenden mit OpenProcess?
1.) nein, mappen heißt eine Page im virtuellen Adressraum eines PRozesses zur Verfügung zu stellen.
2.) Virtueller Speicher ist nicht vorhandener auslagerbarer Speicher, Die Virtualisierung kann aber auch wie gesagt Pages mehreren Prozessen zur Verfügung stellen (Shared Memory) oder aber tatsächlich Diskblöcke in den Adressraum mappen (also auch Dateien).
3.) Ich gehe davon aus, daß Windows den Refcount dekrementiert und falls dieser 0 wird, die Seite wieder freigegeben wird.
4.) Das hängt von der Implementierung des Allocators ab, malloc() ist eine Funktion der Standardbibliothek und diese entscheidet, welche Systemfunktionen sie dazu nutzt. Diese wiederum wird festlegen, wie sie vorgeht. Hättest Du meinen Link gelesen, dann hättest Du vielleicht auch den Abschnitt gelesen, in dem BestFit, FirstFit usw. vorgestellt werden.
5.) Im Prinzip ja, dazu ist der Speicherschutz ja gerade auch gedacht. Hier spielt dann die MMU wieder mit. Zu WriteMemory und OpenProcess kann ich nichts sagen, da Windowsfunktionen.
1.) Das heißt beim Mappen erhält der Prozess sämtliche Pointer mit virtuellen Adressen und mit diesen kann er dann auf die Funktionen zugreifen, die im physischen Speicher in den Pages liegen?
2.) Ich kann es einfach nicht kapieren, was es mit virtuellem Speicher auf sich hat und wofür das gut ist weil ich es nicht verstehe anscheinend und deshalb auch bei 4. keinem Artikel folgen kann.
3.) Das ist wieder logisch, dass heißt wenn eine Dll in 5 Pages im physischen Speicher liegt, dann merkt sich das System die Prozesse die da zugreifen können und wenn kein Prozess mehr zugreift wird es freigegeben.
4.) Warum bin ich zu dumm, das mit virtuellem Speicher zu verstehen? Warum lasse ich einem Programmierer glauben er hätte 4 GB zur Verfügung wenn es nicht stimmt? Da kann ich ja gleich die Wahrheit sagen und ich habe nur 10 Pages zur Verfügung und muss das selber auslagern?
Ich kann es nach vollziehen, dass es physischen Speicher gibt wo ein Programm tatsächlich vorhanden ist und ausgefuehrt wird, aber wo steht das mit dem virtuellen Speicher?
Also angenommen ich mache ein Programm im Debugger auf, dann sehe ich die Memory Map wo alle Module und Daten und Stacks der Reihe nach sichtbar sind.
Und die Memory Map ist dann verteilt auf Pages auf der Festplatte auf dem RAM und im shared Memory? Und weil es mir so angezeigt wird, als wäre alles im RAM heißt es virtuell, obwohl es nicht der Fall ist?
Also, der virtuelle Adressraum ist linear, ich kann Pages, die sonstwie im Speicher veteilt sind (weil ich wegen Fragmentierung keinen ausreichend großen Block finde) zusammenschweißen und so tun, als seien sie ein durchgängiger Block. Die Kachelung flexibilisiert eben.
Im Endeffekt besteht eine virtuelle Adresse (vereinfacht) aus dem Eintrag in der Pagetable und einem Offset innerhalb der Page. [TTTT|OOOOOOOO], die MMU schaut jetzt an Position TTT in der Pagetable, welche physikalische Seite das ist und ersetzt TTTT durch die physische Startadresse. Und schon hast Du eine physikalische Speicheradresse, auf die dann zugegriffen wird.(In realen Implementierungen ist das etwas komplizierter, weil man idR mehrstufig arbeitet)
Bei einem normalen Prozess siehst Du immer nur den virtuellen Adressraum, das ist so gewollt, weil Du so eben Prozesse sauber trennen kannst. Greift ein Prozess auf ungültige virtuelle Adressen zu, dann wird während des Lookups 'abgeblockt' und die physischen Pages sind vor unberechtigten Zugriffen geschützt.
------
1) Das ist seltsam formuliert, im Endeffekt bedeutet mappen, dasß ein Eintrag in der Pagetable vorgenommen wird, sodaß der Prozess dann im entsprechenden Abschnitt des virtuellen Adressraumes auf die zugeordnete Page zugreifen kann - Es ist also eine Verküpfung von logischer Basisadresse mit physiaklischer Basisadresse.
2) Speicherschutz, flexible Speicherverwaltung, Verfügbarkeit von virtuellem Speicher, memory mapped IO, COW-Allocation, Shared Memory, thread-local storage
4) Weil sekundärer Speicher viel billiger als RAM ist und so die Programmierung deutlich vereinfacht wird. Wenn ich eben 4GB für RAW-Audio allokieren möchte, geht das eben trotzdem, auch wenn nur noch 2 GB im physischen RAM frei sind. Andernfalls müßte ich mir überlegen, wie ich das organisiere, daß ich die Datei immer häppchenweise reinhole, verarbeite, Zwischenspeicher etc. pp. - stattdessen überlasse ich das dem OS, das die Funktionalität zentralisiert zur Verfügung stellt.
Also funktioniert das mit virtuellem Speicher nur weil das Offset immer gleich ist?
Weil angenommen ein sehr einfacher Prozess der nur aus 1 exe Modul besteht und 1 Dll wird gestartet.
Dann steht im PE Header ich bevorzuge 0x400000 fuer die Exe und 0x600000 für die Dll.
Dann schreibt das OS diesen Prozess in irgendwelche Random Pages und gaukelt mir vor also im Debugger oder wenn ich Funktionen in der Dll aufrufe, dass sich alles immer der Entry Point auf Offset Exe Base + 0x1000 befindet und die Funktion Hallo in der Dll immer auf 0x6002000 und wenn ich als Programmierer diese Adressen aufrufe komme ich immer auf die wirklichen Adressen dann und alles ist immer linear fuer mich obwohl die MMU die Adresse nimmt, die Base löscht und die Page einfügt und da dann den Offset.
Und das ganze hat den Sinn das man eben die Luecken im RAM besser nutzen kann und sich Prozesse Dlls teilen ohne es "mitzubekommen"?
Und das auslagern der Pages von einem Prozess macht das OS nach bestimmten Kriterien die ich vermutlich beeinflussen kann mit ThreadPriority oder sowas?
Schau Dir bitte folgendne Artikel an:
https://de.wikipedia.org/wiki/Seitentabelle
Hier wird die Funktion der Seitentabelle (Pagetable) mit Bildern erklärt.
Und ja, der Offset in der 'virtuellen' Page und der real dahinter liegenden physischen Page sind identisch - Andernfalls müßtest Du ja für jedes Byte ein getrenntes Mapping führen und könntest Dir die Aufteilung in Pages 'sparen' - Ich sagte bereits eingangs, daß dei Anzahl der Pages überschaubar sein soll. Nun ist das natürlich ein sehr geduldiger Begriff, deswegen gibt es auch mehrstufige Tabellen, invertierte Tabellen oder auch 'Large Pages'.
Also angenommen ich starte einen Prozess.
Und dann braucht Header + Text + Data sagen wir 3 Pages und eine Dll braucht auch 3 Pages.
Dann wird das zuerst mal über die MMU auf irgendwelche 6 Pages die grad frei sind vertwilt und im TBL oder RAM die Tabelle ergänzt mit das gehört zu Prozess oder hInstance "test.exe".
Und wenn ich jetzt eine Funktion in der Dll aufrufe, dann gebe ich der MMU die virtuelle Adresse der Funktion in der Dll und die erkennt dass sich die Adresse auf der Page 5 von diesem Prozess befindet.
Nur kann dass dann nicht immer die Base der Exe sein?
Weil was wenn mitten in einer Funktion eine Page voll ist und die nächste Seite anfängt?
Dann muss die MMU ja erst wieder von jeder einzelnen virtuellen Adresse wissen in welcher Page die ist außer die Page ist schon ein Teil der Adresse, wodurch alle virtuellen Adressen auf Page 5 mit einem Identifier anfangen durch den die MMU das dann zuweisen kann welche Page das ist?
Okay, also, das Prozessimage belege n verschiedene Pages. alle diese Pages werden in der Pagetabelle eingetragen, so daß z.B. das Text-Segment (Code) als auch das Data-Segment aufeinanderfolgende virtuelle Pages belegen.
Vereinfachtes Beispiel, Code belegt 3 Pages:
0000+[Offset], 0001+[Offset], 0010+[Offset] ... Das sind nun die Pages im virtuellen Speicher, die ersten 4 Stellen sind der Index in der Seitentabelle. Entsprechen wird dan 0000 z.B. mit 00110011, 0001 mi 11001111 .. verknüpft. Bei jedem Speicherzugriff bekommt die MMU eine virtuelle Adresse und bildet sie auf die Physikalische Adresse ab.
Rufst Du eine Funktion auf, dann deren virtuelle Adresse, die CPU setzt den IP (Instruction Pointer) auf die neue virtuelle Adresse und holt sich den ersten Befehl, indem die MMU die virtuelle Adresse auf die physikalische abbildet. Und das geht dann immer so weiter, kommst Du am Ende der Page an, liegt die virtuelle Folgeadresse eben in der direkt dahinter liegenden Page im virtuellen Adressraum, die MMU sieht jetzt, ah, neuer Index und holt eben über die Pagetable dann die neue physische Adresse.
------
Die CPU ist dumm, die arbeitet genau das ab, was man ihr sagt, und wenn sie eben einen Befehl aus Adresse XYZ holen soll, dann fragt sie den Speichercontroller, der sagt, wir haben eine virtuelle Adresse, hey, MMU sag mir mal zur virtuellen Base, die physikalische, damit ich weiß, welchem RAM-Baustein ich fragen muß. Nun kann der Speichercontroller die physische Adresse XYZ holen und hält sie der CPU hin und sagt: Hier ist das, was Du haben wolltest.
----------------
Vielleicht machen wir das mal noch dezimal, weil wir das Stellenwertsystem besser kennen, es habe jede Page 1000 Bytes, mit Adressen 000-999 - Das sind 3 Stellen. Habe ich nun eine virtuelle Adresse wie 163011, dann ergibt sich 163|011 -> 163. Eintrag in der Pagetable und Offsett 11, 163|999 Offsett 999 (tausendstes Byte), nun folgt hierauf 164|000 - Das ist das erste Byte der Page mit Index 164.
virt | phys
---------------
0 | 000 | XYZ
... | |
163 | 163 | 881
164 | 164 | 753
Die Doppelung ist nur der Verdeutlichung wegen, weil eben der Offset der Tabelle eben dem Adressanteil entspricht.
Ja so ist es logisch, weil jetzt jeder Offset auf der jeweiligen Page dieselbe Page Indexnummer hat.
Wie eine Straße wo ein Brief hingeht und dort dann die genau Adresse.
Warum hängt die Größe von datenrypen eigentlich vom Rechner ab? Weil die Adressen unterschiedlich lang sein können?
Weil angenommen ich habe eine globale int Variable im data Segment auf Adresse 0x00704000 mit 0x05 00 00 00, wieso ist die sonst bei einem anderen Rechner kleiner?
Oder bezieht sich die Aussage auf vor dem kompilieren?
Die vorherrschende Wortbreite eienr CPU beschreibt deren Verarbeitungsgröße. Hört sich jetzt etwas abstrakt an, aber eine 32-Bit CPU hat (vorwiegend) 32-Bit Register, einen 32-Bit Datenpfad intern. Entsprechend kann sie 32-Bit Werte umstandslos addieren, multiplizieren, usw. usf. . Die Wahrheit ist natürlich, daß auch 32-Bit CPUs über Erweiterungen längere Register für bestimmte Aufgaben besitzen.
Und nicht zu vergessen, der virtuelle Adressraum hat 32-Bit Adressen, entsprechend haben Pointer dann natürlich 32 Bit.
(Der reale pgysische Adressbus ist wieder eien andere Sache, bei 16-Bittern gab es Adressbusse, die breiter als ein CPU-Wort waren, da kam dann eben Segmentierung zum Einsatz, virtuelle Adressierung nach heutigem Schema war da aber oft noch ein Fremdwort.
Also wenn ich ein Int mit einer zu großen Zahl belade fuehrt es bei einem Programm mit zu kleinem Register oder 16 Bit Adressen zu einwm Problem obwohl das Programm anderweitig funktioniert? Wie denn das?
Nein, ganz so einfach ist das nicht. Je nach Sprache wird der Compiler natürlich den Wert runterstutzen und ggf. warnen o.ä. - oder es kommt zum Wrap Around.
Kleinere Wortbreiten stellen in der Regel kein Problem dar, der Grund ist (zumindest bei x86), daß der Opcode für z.B. 32 Bit ebenso von einem 64-Bitter verstanden wird (Abwärtskompatibilität). Umgekehrt geht das allerdings nicht, wenn der Maschinencode Opcodes für 64-Bit Register enthält, würde die CPU im besten Fall mit den Schultern zucken und im schlimmsten irgendwelche anderen Befehle ausführen.
(Ich habe naturgemäß nicht die Opcodes im Kopf, um das abschätzen zu können)
Bevor es aber soweit kommt, wird natürlich das Executeable-Format das schlimmste verhindern, indem das OS die Ausführung verweigert.
Bei den Adressen ist das ein wenig komplizierter. Eine 16 Bit CPU könnte bei einem 16-Bit Adressbus genau 64KB adressieren. In der Regel ist das unbefriedigend, also hat man den Adressbus verbreitert und z.B. die 4 zusätzlichen Bits als Basis genommen:
Sie geben das Segment an, ab dem dann 64 KB linear adressiert werden können - das war bevor man mit virtuellen Adressräumen anfing. Ein ähnliches Konstrukt gab es eine Zeit lang bei 32-Bit CPUs mnit PAE.
Der Puntk ist: Die Größe eines INT ist in der Regel je nach Sprache udn Platform genormt, ist die Größe platformunabhängig, dann muß die Arithmetik eben in Software implementiert werden, so wie bei CPUs ohne FPU mit 'Softfloat'.
Ja aber bei sizeof(int) sieht man ja die Groeße am jeweiligen Rechner und dann ist es nur ein Programm, wenn der Code z. B. in AX also 16 Bit eine 32 Bit Zahl laden will?
Ja weil der Rechner nicht mit 4 BYTE Adressen adressieren kann?
Aber dann hab ich ja Recht damit, weil bei 16 Bit System kommt dann sizeof(int) 2 Byte und darf das Programm nicht mit mehr Byte kompilieren?
Also kamen virtuelle Adressen für die Prozesse nach Win32? Mit der Win32 API in etwa?
https://de.wikipedia.org/wiki/Intel_80286#Protected_Mode
So fing das an ;-). Der 386 war dann schon eine 32 Bit Architektur.
Die von sizeof(int) zurückgelieferte Größe ist Implementierungsabhängig, meine CRT kann auch auf 16 Bit mit 32 Bits arbeiten, wenn es denn sein muß. Ein Compiler würde aber bei einem 16-Bit Target natürlich nie versuchen einen 32-Bit Wert in ein 16-Bit Register zu laden. Wäre ja auch unsinnig.
Das hängt unter anderem zB mit dem Multitasking zusammen. In einen Zusammenhängenden Adressraum müssten alle Programme Positionindepended kompiliert werden. Zudem kann man mehr virtuellen Speicher als tatsächlichen haben.
Außerdem hats auch mit der Sicherheit zu tun dass ein Prozess nicht einfach auf den Speicher eines anderen zugreifen kann.
Der Grund warum man jetzt den Ram in Pages aufteilt hängt mit der Komplexität der MMU zusammen.
Wenn man dieser einfach nur eine Startadresse oder einen Index für die Page gibt macht das die Schaltung einfacher als wenn man Startadresse + Größe usw in Hardware abbilden muss.
Das Paging verhindert zudem Speicherfragmentierung da der Speicher in fixen Blöcken zugeteilt wird. Durch die Fragmentierung könnte es nämlich so weit kommen dass zB einem Prozess speicher nur noch in vielen kleinen Blöcken zugeteilt werden könnte was natürlich eine große Pagetable bedingen würde.
Btw das was du meinst nennt sich Segmentierung und das würde zB früher so gemacht. Die Malloc Funktion in C funktioniert zB immer noch so.
Was heißt das erste? Wenn ich ein Programm starte dann weiß ich ich will sagen wir 100 MByte RAM für mein Programm. Und dann frage ich die MMU an und die gibt mir halt das was frei ist?
Das wäre auch kein Problem wenn das System buchführt welcher Prozess welchen Adressraum reserviert hat?
Das heißt weil es einfacher ist zu beurteilen: Prozess eins beansprucht Page 1 - 3 und Prozess beansprucht Page 4 - 5? Und wenn der Prozess eins eine weitere Page will, dann schaut die MMU nach, sieht 4 und 5 ist vergeben also gibt sie 6 her oder 7.
Und somit kann man gar nicht weniger Speicher reservieren als eine Page? Und auch wenn man malloc 1 Byte called, erhält man eine neue Page? Oder schreibt etwas in der eigenen Page um die man schon hat? Was die MMU auch wieder wissen muss?
Das mit der Fragmentierung könnte ich verstehen, weil wie ob: Wenn ein Programm einen Error meldet dann gibt Windows alle Pages frei die dieses Programm hatte und weiß es gibt keine kleine Lücken die man nicht mehr sinnvoll nützen kann?
Ich hab es mir so vorgestellt, dass es wie bei Adressen ist wo der Briefträger weiß die Post ist für dieses Grundstück. Um die Adressen zu gliedern quasi.
Das erste ist der Grund warum es überhaupt eine MMU und einen virtuellen Adressraum gibt.
Es wäre kein Problem Buch zu führen, aber eine Aufteilung in Prozess 1 belegt Page 1 und 2, Prozess 2 belegt Page 3 und 8 usw. ist effektiver als Process belegt 1MB Speicher mit Basisadresse x und 2MB mit Basisadresse y usw.
Zumal man auch hier zumindest die Word Boundaries einhalten muss. Sprich das Alignment der Speicherbereiche muss ohnehin wieder passen womit es wieder eine kleinst mögliche Blocksize geben würde.
Dem Programm kann nicht weniger Speicher als eine Page zugeordnet sein.
Wenn man bei Malloc 1 Byte anfordert bekommt man nicht unbedingt eine neue Page. Malloc arbeitet über Segmentierung sprich es schaut nach wo und ob überhaupt Speicher im Heap frei ist. Wenn einer frei ist dann wird ein Pointer zurückgegeben und Malloc speichert die Basisadresse + Größe. Die MMU gibt dem Prozess erst eine neue Page wenn Virtueller Speicher angefordert wird welcher noch keiner Page zugeordnet wurde.
Anders gesagt Malloc hat keinen Einfluss auf die MMU oder welche Pages zugeteilt werden. Ich habe Malloc hier nur als Beispiel angeführt wie Segmentierung funktioniert.
Und wie ist das bei den Dlls? Ich starte Windows, dann kopiert es die Kernel32.dll auf sagen wir 5 Pages im physischen RAM.
Jetzt starte ich ein Programm, das über die .lib implizit die Kernell32.dll ladet.
Dann führt quasi Windows Buch darüber, welche Dlls schon Speicher sind.
Also fragt es irgendwo an ob die Dlls schon im RAM vorhanden ist oder nicht? Über den Namen oder die hInstance?
Und ich sehe in jedem Programm im virtuellen Speicher die Dlls die aber auf derselben Adresse im physischen RAM liegt?
Und mein Programm will Sleep ausführen, also fragt es bei der MMU diese Adresse an und die verweist auf die Page 3 und den Offset 0x25 und da liegt dann die Funktion und wird von der CPU ausgeführt?
Ja das OS weiß welche DLLs geladen sind und wo sie stehen. Ich würde mal sagen, dass es dazu eine Tabelle mit IDs hat. Über den Namen glaub ich nicht, weil es theoretisch mehre DLLs mit dem selben Namen geben kann. Sie müssen nur einen unterschiedlichen Pfad haben.
Genau die DLL wird in den Virtuellen Speicher der Programme gemapped.
Mehr oder weniger. Das Programm greift einfach nur auf den jeweiligen Bereich im Virtuellen Adressraum zu. Die CPU verwendet jetzt die MMU und verweist dann auf den physikalischen Speicher.
Für das Programm selbst ist das ganze vollkommen transparent, sprich es muss nichts von der MMU wissen und es muss auch nicht mal wissen ob der Ram virtuell oder physikalisch ist usw.
Man nutzt virtuelle Pages, oder auch virtuellen Speicher, damit man mehr Speicherplatz nutzen kann. Sonst müssten sich alle Programme den gleichen Adressraum teilen, was den Speicher schnell an seine Grenzen führt.
Wenn man einem Prozess X MB zur Verfügung stellt, dann kann es nicht noch mehr Speicher nutzen, obwohl es ihn braucht. Daher gibt es die dynamische Speichereinteilung mit virtuellen Addressen, TLB, der MMU etc.
Das heißt eine Page hat immer z. b. 64kbit. Jetzt steht im Imageheader ich brauche 0x3000 Bytes. Also werden 1 Page reserviert mit Readonly da kommt der Header hin, 1 Page mit executable da kommen die Funktionen und 1 Page mit Readonly für rdata.
Und die Page 1 bekommt dann einen bestimmten Platz im wirklichen RAM oder kann auf die Festplatte ausgelagert werden?
Hat eine Page aber keine einheitliche Speicherprotection? Weil mit VirtualAlloc kann man ja auch ein paar Bytes ändern?
Und ist das die kleinste Einheit die ich reservieren kann? Also reserviert auch ein Programm mit 1000 Bytes eine ganze Page?
Warum reserviert man für ein bestimmtes Programm nicht einfach 5 MB anstelle von n Pages?
Genau deshalb, weil man dann nicht für jedes Programm 5MB reservieren muss!
Wie sollte dein Webbrowser ohne dynamischen Speicher so bitte funktionieren?
Du kannst n Tabs öffnen und bei n+1 Tabs stürzt der Browser ab? Wie stellst du dir das vor? :)
Wieso der Webbrowser bzw. der Prozess reserviert ja grundsätzlich immer 4GB auf 32 Bit System?
Gibt es die Pages quasi nur damit das System bzw. MMU sich die Page merkt wo etwas liegt im echten RAM oder Festplatte und nicht alle Adressen Buchführen muss?
Kein Browser der Welt reserviert ohne Not 4GB. Da hast du grundlegend etwas falsch verstanden.
Ich dachte jeder Prozess bekommt seine 4GB virtuellen Speicher?
Achso ich hab glaub mit YouTube Videos jetzt das ganze etwas besser verstanden. Wenn man einen Prozess startet dann ist der mögliche Speicherbereich 4GB aber der tatsächliche nur die Pages welche Header, Code und Daten braucht.
Und wenn der Stack größer wird oder man etwas am Heap reserviert beansprucht der Prozess zur Laufzeit neue Pages.
Also angenommen man hat 100 Byte Speicher und zerlegt das in 10 Kacheln.
Dann weiß das System es gibt 10 Kacheln zu 10 Byte.
Was soll das heißen mit mehreren Prozess im Kontext zur Verfügung stellen? Was ist hier ein Beispiel?
Kachel auslagern heißt dann wenn die CPU anfragt sie will Kachel 7 haben, dann verweist es auf eine Adresse auf der Festplatte?
Dann sind Kacheln ja schlecht, weil dann muss man immer unnötig alles Laden was in der Kachel ist?