Conferința vbstreets - vizualizați subiectul - memoria virtuală

Am decis să atingem acest subiect în legătură cu un număr mare de concepții greșite și neînțelegeri pe această temă (inclusiv aici pe forum).

Din cauza acestei coincidențe, mitul sa răspândit că Windows nu poate aloca mai mult de 4 GB de memorie tuturor programelor în total. De fapt, chiar fără PAE, prezența schimbării vă permite să alocați toate procesele în cantitate de 64 GB de memorie: Windows vă permite să aveți până la 16 fișiere de paginare, până la 4 GB fiecare. Cu PAE, această restricție este extinsă la 256TB (16x16TB).








* Pentru a simplifica lucrul cu memoria virtuală, se folosește organizarea paginii: toată memoria este împărțită în pagini egale (în Windows - 4Kb fiecare) și aceiași parametri se aplică întregii pagini. Pagina virtuală AP poate fi în una din cele trei stări: liberă, rezervată, ocupată. Diferența dintre o pagină liberă și una rezervată este numai că pagina rezervată nu poate fi returnată de funcțiile de alocare a memoriei; prin urmare, structurile continue în creștere dinamică (de exemplu, stive de fluxuri) la creație sunt rezervate în întregime. Acest lucru asigură faptul că partea goală a volumului rezervat pentru stiva va rămâne goală până când va trebui să ocupe stiva extinsă.

O pagină ocupată poate fi una din cele două tipuri: backup-uri (imagine fișier: modul executabil încărcat sau cartografiere de fișiere create în mod explicit) sau swap-backed; și indiferent de tipul său, pagina ocupată poate fi în una din două poziții: încărcată (adică corespunde paginii OP) sau descărcată. Paginile cu back-up descărcate nu sunt stocate nicăieri; dacă este necesar, sunt încărcate din nou din același fișier din care au fost create. Paginile swap-backed care sunt descărcate sunt stocate în fișierul swap (win386.swp pe Win9x, pagefile.sys pe WinNT). Apropo: schimbarea a apărut pentru prima dată în Windows / 386, deoarece procesorul 386 a sprijinit pentru prima dată organizarea paginii de memorie. API-urile virtuale au fost posibile din 286, dar în Windows au fost folosite doar de la WinNT 3.1. Descărcarea resurselor neutilizate din memorie și încărcarea acestora dintr-un fișier exe de pe disc, precum și îmbinarea mai multor secțiuni ale aceluiași program în memorie au existat încă de la Windows 1.0.

Este important ca paginile swap-backed să fie adăugate la fișierul de swap de pe disc nu în momentul descărcării, ci la momentul creării - astfel încât la momentul încărcării să fie sigur că pagina este locul unde să se descarce. Prin urmare, fișierul swap este atât de mare. chiar dacă nu există o singură pagină de tip swap-backed în întregul sistem, este rezervat un loc pentru toți "în cazul lansării bruște a 15 copii ale Photoshop-ului."

Puteți schimba tipul de pagină într-o singură direcție - de la fișierul backed la swap-backed (acest lucru se face apelând VirtualProtect). După această modificare, pagina începe să ocupe un loc în fișierul swap. În cazul în care cererea este auto-modificarea codului (de exemplu, în cazul în care este ambalat UPX sau înveliș similar), este atunci când solicitați acces de scriere la secțiunea lor de cod traduce paginile sale în tip sprijinit-swap, și ca urmare a acestei cereri ocupă mai mult spațiu pe disc (deoarece fișierul de swap acum stochează imaginea sa despachetată în întregime). În cazul în care o astfel de cerere comprimat pentru a rula a doua oară, și în memoria și fișierul de swap va crea o altă copie a imaginii decomprimat - în timp ce fără ambalator în noul proces va fi proiectat pe aceeași pagină a AF, în care a fost înainte de prima instanță a codului este încărcat. Deci, aplicațiile ambalate ocupă mai mult spațiu decât aplicațiile neambalate - atât pe disc cât și în memorie. Nu știu de ce, și pentru care sa întâmplat să fie implicată într-o astfel de nebunie.







Ultimul din acest domeniu este conceptul de "set de lucru". Acesta este un set de pagini de proces AP care sunt ocupate și în stare încărcată (indiferent de tipul lor). Acest volum este afișat în coloana "Mem Utilizare" din fila "Procese" din Managerul de activități. Acest număr se poate schimba, chiar dacă procesul nu face nimic: sistemul însuși decide când să încarce și să descarce paginile din memoria sa. Și graficul "Mem Utilizare" din fila următoare "Performanță" reflectă un alt volum - volumul tuturor paginilor însoțite de swap (indiferent de poziția lor). (În ultimele versiuni de Windows, a fost în cele din urmă redenumit la "Utilizarea fișierelor de pagină".) Acest grafic arată alocarea și eliberarea proceselor de memorie virtuală și nu are nimic de-a face cu încărcarea FP. Nu este surprinzător faptul că suma tuturor numerelor de pe o filă nu va fi egală cu numărul pe cealaltă: aceste numere reflectă lucruri destul de diferite.


* Pe paginile VI, cu excepția asocierii cu un anumit spațiu de stocare (OP și / sau fișier), există și un mod de acces. Pe lângă drepturile standard (citire, scriere, executare), este acceptat un alt steag neobișnuit - PAGE_GUARD. Pagina „minat“ cu acest pavilion: funcționează ca o pagină normală ocupat, dar atunci când încercați mai întâi să accesați se întâmplă STATUS_GUARD_PAGE_VIOLATION excepție, iar steagul este eliminat. Poate pentru acest steguleț, puteți veni cu o grămadă de aplicații diferite, dar știu doar un lucru - prelucrarea stivei de suprapunere.

Stack-ul de auto-extindere funcționează, în general, după cum urmează. rezervat inițial volumul de aplicare din titlu (implicit - 1MB), partea superioară (partea de sus a stivei) se angajează, și chiar mai jos o parte zakommichennoy a creat „pagina minat.“ Handlerul de excepții de pe această pagină, respectiv, comite stivuirea în jos, creând un nou AP sub noua parte. Când toată porțiunea rezervată zakommichena stiva continuă să crească nu se poate: noul AP nu este creat, și încercarea de a avea acces dincolo de stiva duce la o defecțiune convențională de protecție a memoriei „de memorie nu poate fi«scris»“.

tyomitch a scris: dacă a fost lansat, sa prăbușit și nu a fost folosit pentru o lungă perioadă de timp câteva copii ale notorii Photoshop, nimic mai mult nu se poate face cu sistemul mai.


Am verificat? Photoshop utilizează propriul mecanism swap, independent de Windows.

De asemenea, în măsura în care îmi amintesc, cel puțin un server avansat este necesar pentru a rula / 3 GB.

Ennor
Photoshop probabil nu este cel mai de succes exemplu. Dar dacă rulați Quake 4 fără o schimbare pe un gigabyte, sistemul va țipa că nu este suficient RAM.

Am verificat? Photoshop utilizează propriul mecanism swap, independent de Windows.

tyomitch a scris: dacă a fost lansat, sa prăbușit și nu a fost folosit pentru o lungă perioadă de timp câteva copii ale notorii Photoshop, nimic mai mult nu se poate face cu sistemul mai.


Am verificat? Photoshop utilizează propriul mecanism swap, independent de Windows.

Ennor a scris: În ceea ce îmi amintesc, pentru muncă / 3 GB, este necesar un server avansat.


În MSDN, exact după linkul pe care l-am citat, sunt listate sistemele suportate. Copiați aici în mod specific pentru oamenii leneși sau ce? În orice caz, WinXP Pro se află pe această listă.

Văd, da; amestecat cu platforma serverului, îmi pare rău.

O notă despre EXCEPTION_STACK_OVERFLOW de la Chris Kasperski (dacă cineva este interesat):

myshch a scris (): Am crezut cumva că EXCEPTION_STACK_OVERFLOW apare
când se referă la pagina penultimă a stivei, după care
sistemul ne aloca o nouă pagină pe care am putea-o cumva
procesați excepția care a avut loc.

dar când accesați limitele stivei, o EXCEPTION_ACCESS_VIOLATION

Și eu practic practic medicina pe bază de plante.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: