Te informacje o systemie pochodzą z Process Explorer. Nadal dostępna jest pamięć fizyczna, ale system prawie nie pokazuje pamięci RAM.

Menedżer zadań pokazuje również, że zużywa około 74% całkowitej pamięci RAM.

Od czasu zainstalowania systemu Windows 8.1 komputer miał 4 + 8 = 12 GB pamięci RAM. Zaktualizowałem go, zmieniając 4 GB na moduł 8 GB. Czy to może być problem? Czy to zachowanie jest normalne i po prostu źle zrozumiałem znaczenie dostępnej pamięci fizycznej?

Krótka odpowiedź

Wyskakujące okienko „brak pamięci” mówi, że wyczerpałeś limit prywatnej pamięci - rodzaj pamięci wirtualnej. Nie, że kończy Ci się pamięć RAM (pamięć fizyczna). Nie ma znaczenia, ile masz dostępnej pamięci RAM. Posiadanie dużej ilości dostępnej pamięci RAM nie pozwala na przekroczenie limitu zatwierdzeń. Limit zatwierdzeń to suma całkowitej pamięci RAM (w użyciu lub nie!) Plus bieżący rozmiar pliku strony.

I odwrotnie, to, co „zużywa” limit zatwierdzania (który w większości polega na tworzeniu prywatnej wirtualnej przestrzeni adresowej procesu) niekoniecznie wykorzystuje pamięć RAM! Ale system operacyjny nie zezwoli na jego utworzenie, chyba że będzie wiedział, że jest miejsce do przechowywania go, jeśli zajdzie taka potrzeba. Możesz więc wpaść na limit zatwierdzeń bez użycia całej pamięci RAM, a nawet większości pamięci RAM.

Dlatego nie powinieneś uruchamiać się bez pliku strony. Pamiętaj, że plik strony może nigdy nie zostać zapisany! Ale nadal pozwoli ci uniknąć błędów „brak pamięci” i „brak pamięci”.

Odpowiedź pośrednia

System Windows nie wyświetla komunikatu o błędzie w przypadku braku pamięci RAM. To, czego Ci brakuje, to „limit zatwierdzeń”.

Wykres „System” w tej wersji Process Explorera jest źle nazwany. Powinien być oznaczony jako „zatwierdzić opłatę”. (W wersji, którą mam, nazywa się to „Zatwierdzenie systemu”. Lepsze, ale wciąż nie do końca spójne.) W każdym razie „obecna” wysokość wykresu pokazuje to, co jest poniżej w sekcji tekstowej jako „Commit Charge” - „ Bieżący ”, a maksymalna wysokość wykresu reprezentuje„ Commit Charge ”-„ Limit ”.

„Opłata za zatwierdzenie” odnosi się do wirtualnej przestrzeni adresowej, która jest wspierana przez plik stronicowania (jeśli taki masz) - innymi słowy, jeśli nie wszystko zmieści się w pamięci RAM, reszta trafi do pliku stronicowania. (Istnieją inne typy plików vas, które są wspierane przez inne pliki - tak zwane pliki „mapowane” - lub które muszą pozostać w pamięci RAM przez cały czas; ten drugi jest nazywany „niestronicowanym”.) „Limit zatwierdzeń” to maksimum, które „opłata za zatwierdzenie” może być. Jest równy rozmiarowi pamięci RAM plus rozmiar pliku stronicowania.

Najwyraźniej nie masz pliku stronicowania (mogę powiedzieć, ponieważ twój limit zatwierdzeń równa się rozmiarowi pamięci RAM), więc limit zatwierdzeń jest po prostu rozmiarem pamięci RAM.

Najwyraźniej różne programy + system operacyjny wykorzystały prawie wszystkie maksymalne możliwe zatwierdzenia.

Nie ma to bezpośredniego związku z ilością wolnej lub dostępnej pamięci RAM. Tak, masz około 4,5 GB dostępnej pamięci RAM. To nie znaczy, że możesz przekroczyć limit zatwierdzeń. Zaangażowana pamięć niekoniecznie korzysta z pamięci RAM i nie jest ograniczona ilością dostępnej pamięci RAM.

Musisz albo ponownie włączyć plik stronicowania - przy takim zaangażowaniu zasugerowałbym plik stronicowania o wielkości 16 GB, ponieważ nie chcesz wymuszać na systemie operacyjnym przechowywania tak wielu rzeczy w pamięci RAM, a plik stronicowania działa najlepiej, jeśli ma dużo wolnego miejsca - lub dodać więcej pamięci RAM. Dużo więcej. Aby uzyskać dobrą wydajność, musisz mieć dużo miejsca w pamięci RAM na kod i inne rzeczy, które nie są wspierane przez plik stronicowania (ale mogą być stronicowane do innych plików).

Bardzo długa odpowiedź

(ale wciąż znacznie krótszy niż rozdział dotyczący zarządzania pamięcią w Windows Wewnętrznych ...)

Załóżmy, że program przydziela 100 MB prywatnej pamięci wirtualnej procesu. Odbywa się to za pomocą wywołania VirtualAlloc z opcją „zatwierdzenia”. Spowoduje to zwiększenie o 100 MB wartości „Commit charge”. Ale ten „przydział” tak naprawdę nie wykorzystuje pamięci RAM! Pamięć RAM jest używana tylko wtedy, gdy po raz pierwszy uzyskano dostęp do nowo przydzielonej wirtualnej przestrzeni adresowej .

Jak pamięć RAM w końcu się zużywa

(jeśli kiedykolwiek tak jest)

Pierwszym dostępem do nowo zatwierdzonego miejsca prawie zawsze byłby zapis do pamięci (odczytanie nowo przydzielonego prywatnego vasa przed zapisaniem jest prawie zawsze błędem programowym, ponieważ jego początkowa zawartość jest, ściśle mówiąc, nieokreślona). Ale czytając lub pisząc, wynik, gdy po raz pierwszy dotkniesz strony nowo przydzielonego nasieniowodu, jest błędem strony . Chociaż słowo „błąd” brzmi źle, błędy strony są całkowicie oczekiwanym, a nawet wymaganym zdarzeniem w systemie operacyjnym pamięci wirtualnej.

W odpowiedzi na ten szczególny rodzaj błędu strony pager (część menedżera pamięci systemu operacyjnego, który czasami nazywam „Mm”):

1. przydziel fizyczną stronę pamięci RAM (najlepiej z listy zerowej strony, ale w każdym razie pochodzi ona z tego, co Windows nazywa „dostępnym”: zerowa, wolna lub rezerwowa lista stron, w tej kolejności preferencji);
2. wypełnij pozycję tabeli stron, aby powiązać stronę fizyczną ze stroną wirtualną; i w końcu
3. odrzuć wyjątek błędu strony.

Po tym czasie kod, który zrobił odwołanie do pamięci, ponownie wykona instrukcję, która spowodowała błąd strony, i tym razem odniesienie się powiedzie.

Mówimy, że strona została „uszkodzona” w zestawie roboczym procesu i w pamięci RAM. W Menedżerze zadań będzie to widoczne jako jednostronicowy (4 KB) wzrost w „prywatnym zestawie roboczym” procesu. I jednostronicowe zmniejszenie dostępnej pamięci fizycznej. (Ta ostatnia może być trudna do zauważenia na ruchliwym komputerze).

Uwaga 1: Ten błąd strony nie obejmował niczego odczytanego z dysku. Nigdy wcześniej nie otwierana strona zatwierdzonej pamięci wirtualnej nie rozpoczyna życia na dysku; to nie ma miejsca na dysku, aby przeczytać go od . Jest po prostu „zmaterializowany” na poprzednio dostępnej stronie pamięci RAM. Statystycznie, w rzeczywistości większość błędów stron jest rozwiązywana w pamięci RAM, albo do współużytkowanych stron, które są już w pamięci RAM dla innych procesów, albo do pamięci podręcznej stron - rezerwowych lub zmodyfikowanych list, lub jako strony „zerujące” takie jak ta.

Uwaga 2: To zajmuje tylko jedną stronę, 4096 bajtów, z „Dostępne”. Nigdy wcześniej nie dotykana zatwierdzona przestrzeń adresowa jest zwykle realizowana - powodowana błędem - tylko jedna strona na raz, ponieważ każda strona jest „dotykana” po raz pierwszy. Robienie więcej naraz nie byłoby żadnej poprawy, żadnej korzyści; zajęłoby to n razy więcej czasu. Natomiast gdy strony muszą być odczytywane z dysku, podejmowana jest pewna próba „readahead”, ponieważ znaczna większość czasu podczas odczytu dysku odbywa się na koszt operacji, a nie faktyczny transfer danych. Kwota „zatwierdzona” pozostaje na poziomie 100 MB; fakt, że jedna lub strony zostały uszkodzone, nie zmniejsza opłaty za zatwierdzenie.

Uwaga 3:Załóżmy, że mamy 4 GB „dostępnej” pamięci RAM. Oznacza to, że moglibyśmy odwoływać się do przydzielonej już, ale nigdy wcześniej nie wymienionej, zatwierdzonej pamięci około milion razy więcej (4 GB / 4096), zanim zabraknie nam pamięci RAM. W tym momencie, jeśli mamy plik strony, jak zamierzali David Cutler i Lou Perazzoli, niektóre z najdłużej odwoływanych stron w pamięci RAM byłyby zapisywane na dysku, a następnie udostępniane do użytku w usuwaniu najnowszych błędów stron. (W rzeczywistości system operacyjny zainicjowałby metody odzyskiwania pamięci RAM, takie jak „przycinanie zestawu roboczego”, a rzeczywiste zapisy do pliku strony są buforowane i umieszczane na zmodyfikowanej liście stron w celu zwiększenia wydajności i ...) Żadne z tych działań nie wpłynęłoby na liczba „popełnionych”. Jest to jednak istotne dla „limitu zatwierdzeń”. Jeśli nie ma miejsca na wszystkie „

I tak się dzieje ...

Przypuśćmy jednak, że nie zrobiliśmy jeszcze miliona referencji, a strony „dostępne” są nadal warte około 4 GB. Załóżmy teraz, że ten sam proces - lub inny, nie ma znaczenia - wykonuje kolejny VirtualAlloc, tym razem powiedzmy 200 MB. Ponownie, 200 MB zostaje dodane do opłaty zatwierdzenia i nie usuwa dostępnej pamięci RAM. Po prostu VirtualAlloc'ująca przestrzeń adresowa nie zużywa odpowiedniej ilości pamięci RAM, a posiadanie niskiej „dostępnej” pamięci RAM nie ogranicza ilości przestrzeni adresowej, którą można VirtualAlloc (ani nie ma wysokiej dostępnej pamięci RAM, aby ją zwiększyć).

(Cóż, ok ... jest niewielki narzut, wynoszący jedną (stronicowalną!) Stronę, która jest używana na tabelę stron na każde 2 MB (4 MB, jeśli używasz systemu x86 bez PAE) przydzielona wirtualna przestrzeń adresowa, a dla każdego praktycznie ciągłego przydzielonego zakresu istnieje „deskryptor adresu wirtualnego” zawierający kilkadziesiąt bajtów).

W ten sposób jest to możliwe - i powszechne! - aby zużyć dużo „opłaty zatwierdzenia” przy użyciu tylko niewielkiej ilości pamięci RAM.

Jeśli więc „zatwierdzanie” wirtualnej przestrzeni adresowej nie zużywa pamięci RAM, dlaczego musi istnieć limit?

Ponieważ „opłata zatwierdzenia” reprezentuje potencjalne przyszłe wykorzystanie przestrzeni dyskowej. „Limit zatwierdzania” reprezentuje całkowitą ilość pamięci (RAM + miejsce na plik stronicowania) dostępną do przechowywania takich przydziałów, w przypadku , gdyby kiedykolwiek faktycznie istniały do ​​nich odniesienia, a zatem należy je gdzieś przechowywać.

Kiedy Mm zatwierdzi żądanie VirtualAlloc, obiecuje - „zobowiązując się” - że wszystkie kolejne dostępy do pamięci do przydzielonego obszaru zakończą się powodzeniem; mogą powodować awarie strony, ale wszystkie usterki będą mogły zostać usunięte, ponieważ istnieje wystarczająca ilość miejsca do przechowywania zawartości wszystkich tych stron, czy to w pamięci RAM, czy w pliku stronicowania. Mm wie o tym, ponieważ wie, ile jest miejsca w pamięci (limit zatwierdzeń) i ile już zostało „zatwierdzonych” (bieżąca opłata za zatwierdzenie).

(Ale do wszystkich tych stron nie zawsze jeszcze uzyskano dostęp, więc niekoniecznie musi istnieć faktyczna ilość miejsca do przechowywania z przydzieloną kwotą w danym momencie).

Więc ... Co z „brakiem pamięci w systemie”?

Jeśli spróbujesz VirtualAlloc, a bieżąca opłata za zatwierdzenie plus żądany rozmiar alokacji przejmie limit zatwierdzeń, ORAZ system operacyjny nie może rozwinąć pliku stronicowania, aby zwiększyć limit zatwierdzeń ... otrzymujesz komunikat „z pamięci” w górę, a proces widzi wywołanie VirtualAlloc FAIL. Większość programów po prostu podnosi ręce i umiera w tym momencie. Niektóre będą ślepo naciskać, zakładając, że połączenie się powiodło, a później nie powiedzie się, gdy będą próbować odwołać się do regionu, który im przydzielono.

Znowu (przepraszam za powtórzenie): nie ma znaczenia, ile masz dostępnej pamięci RAM. System operacyjny obiecał, że pamięć RAM lub miejsce na stronie będzie dostępne, gdy będzie potrzebne, ale obietnica ta nie odejmuje się od „Dostępne”. Dostępna pamięć RAM jest wykorzystywana tylko przez zatwierdzoną maszynę wirtualną, gdy jest przywoływana po raz pierwszy, co powoduje, że jest ona „zakłócana” ... tj. Realizowana w pamięci fizycznej. I po prostu zatwierdzenie (= przydzielenie) pamięci wirtualnej tego nie robi. Zajmuje tylko bezpłatną wirtualną przestrzeń adresową i czyni z niej użyteczną wirtualną przestrzeń adresową.

Ale w przypadku „braku pamięci” pojawiło się żądanie alokacji pamięci zatwierdzonej, a system operacyjny dodał bieżącą opłatę zatwierdzenia do wielkości tego nowego żądania ... i stwierdził, że suma jest większa niż limit zatwierdzeń. Więc jeśli system operacyjny zatwierdzi ten nowy, a po tym odwołanie do całej tej przestrzeni, nie będzie żadnych prawdziwych miejsc (RAM + plik stronicowania) do przechowywania tego wszystkiego.

System operacyjny nie pozwoli na to. Nie pozwoli na przydzielenie większej ilości waz, niż ma miejsce, aby zachować go w najgorszym przypadku - nawet jeśli wszystko zostanie „zakłócone”. Taki jest cel „limitu zatwierdzeń”.

Mówię ci trzy razy Mówię ci trzy razy Mówię ci trzy razy: Ilość „dostępnej” pamięci RAM nie ma znaczenia. To, że zatwierdzona przestrzeń wirtualna nie wykorzystuje jeszcze całej przestrzeni dyskowej, nie ma znaczenia. System Windows nie może „zatwierdzić” wirtualnego przydziału, chyba że „w przyszłości” będzie można zarzucić błąd.

Należy zauważyć, że istnieje inny typ vas zwany „mapowany”, używany głównie do kodu i dostępu do dużych plików danych, ale nie jest obciążany „opłatą zatwierdzenia” i nie jest ograniczony przez „limit zatwierdzania”. Wynika to z tego, że ma własny obszar pamięci, pliki „zamapowane” na niego. Jedynym ograniczeniem „zmapowanych” waz jest ilość miejsca na dysku, które masz na zamapowane pliki, oraz ilość wolnych waz w procesie ich mapowania.

Ale kiedy patrzę na system, nie jestem jeszcze na granicy zatwierdzeń?

Zasadniczo jest to problem dotyczący pomiaru i prowadzenia rejestrów. Patrzysz na system po tym, jak połączenie VirtualAlloc zostało już wypróbowane i zakończyło się niepowodzeniem.

Załóżmy, że masz tylko 500 MB limitu zatwierdzeń, a jakiś program próbował VirtualAlloc 600 MB. Próba kończy się niepowodzeniem. Następnie spójrz na system i powiesz „Co? Zostało jeszcze 500 MB!” W rzeczywistości do tego czasu może być o wiele więcej, ponieważ do tego momentu proces ten prawdopodobnie całkowicie zniknął, więc WSZYSTKIE wcześniej przydzielone pamięci zostały zwolnione.

Problem polega na tym, że nie można spojrzeć w przeszłość i zobaczyć, jaka była opłata za zatwierdzenie w momencie podjęcia próby alokacji. Nie wiesz też, ile miejsca zajęła ta próba. Nie można więc definitywnie zrozumieć, dlaczego próba się nie powiodła, ani o ile więcej „limit zatwierdzenia” byłby potrzebny, aby umożliwić jej działanie.

Widziałem „w systemie zaczyna brakować pamięci”. Co to jest?

Jeśli w powyższym przypadku system operacyjny MOŻE rozwinąć plik stronicowania (tzn. Pozostawisz domyślną wartość „zarządzaną przez system” lub zarządzasz nim, ale ustawisz maksymalną wartość na większą niż początkowa, ORAZ wystarczającej ilości wolnego miejsca na dysku), i takie rozszerzenie zwiększa limit zatwierdzenia wystarczająco, aby pozwolić na powodzenie wywołania VirtualAlloc, a następnie ... Mm rozszerza plik stronicowania, a wywołanie VirtualAlloc kończy się powodzeniem.

I wtedy pojawia się komunikat „System działa NISKO w pamięci”. Jest to wczesne ostrzeżenie, że jeśli wszystko będzie kontynuowane bez łagodzenia, prawdopodobnie wkrótce pojawi się ostrzeżenie o braku pamięci. Czas zamknąć niektóre aplikacje. Zacznę od okien przeglądarki.

Myślisz, że to dobra rzecz? Rozszerzenie pliku stronicowania jest złe!

Nie, nie jest. Widzisz, system operacyjny tak naprawdę nie „rozszerza” istniejącego pliku. Po prostu przydziela nowy zakres. Efekt jest podobny do każdego innego niesąsiadującego pliku. Stara zawartość pliku strony pozostaje tam, gdzie się znajduje; nie trzeba ich kopiować w nowe miejsce ani nic takiego. Ponieważ większość operacji we / wy pliku strony ma stosunkowo małe porcje w porównaniu do rozmiaru pliku strony, szanse, że jakikolwiek transfer przekroczy granicę zasięgu, są naprawdę dość rzadkie, więc fragmentacja nie zaszkodzi, chyba że jest naprawdę nadmierna.

Wreszcie, gdy wszystkie procesy, które „zatwierdziły” miejsce w rozszerzeniu, zostały zakończone (przy zamykaniu systemu operacyjnego, jeśli nie wcześniej), zakresy są cicho zwalniane, a plik strony powróci do poprzedniego rozmiaru i przydziału - jeśli wcześniej był ciągły, tak jest znowu.

Zezwolenie na rozszerzenie pliku strony działa zatem jako całkowicie darmowa sieć bezpieczeństwa: jeśli na to zezwolisz, ale system nigdy tego nie potrzebuje, system nie będzie „stale rozszerzał i kurczył pliku strony”, jak często się twierdzi, więc nic nie kosztuje . A jeśli będziesz go kiedykolwiek potrzebować, uratuje Cię to przed awariami aplikacji z błędami „brak pamięci wirtualnej”.

Ale ale ale ...

Przeczytałem na kilkudziesięciu stronach internetowych, że jeśli zezwolisz na rozszerzenie pliku strony, Windows będzie stale rozszerzać i kurczyć plik strony, co spowoduje fragmentację pliku strony, dopóki go nie zdefragmentujesz.

Po prostu się mylą.

Jeśli nigdy nie widziałeś wyskakującego okienka „zaczyna brakować pamięci” (lub, w starszych wersjach, „zaczyna brakować pamięci wirtualnej”), system operacyjny nigdy nie rozwinął pliku stronicowania.

Jeśli zobaczysz to okienko wyskakujące, oznacza to, że początkowy rozmiar pliku strony jest za mały. (Chciałbym ustawić go na około 4x maksymalne zaobserwowane użycie, tj. Licznik perfmon „% szczytowego użycia pliku stronicowania” powinien wynosić poniżej 25%. Powód: Przestrzenią pliku stronicowania zarządza się jak każdą inną stertą i działa najlepiej z dużą ilością wolnego miejsca grać.)

Ale dlaczego po prostu ...

Można argumentować, że system operacyjny powinien po prostu pozwolić na alokację, a następnie dopuścić do niepowodzenia referencji, jeśli nie ma dostępnej pamięci RAM do usunięcia błędów strony. Innymi słowy, powyżej, gdzie opisaliśmy, jak działa początkowa usterka strony, co się stanie, jeśli „przydzielenia dostępnej fizycznej strony pamięci RAM” (krok 1) nie można zrobić, ponieważ nie było żadnej dostępnej i nie było miejsca pozostawione, by znaleźć coś na stronie, aby je udostępnić?

Wtedy pager nie byłby w stanie rozwiązać błędu strony. Musiałby umożliwić raportowanie wyjątku (błąd strony) z powrotem do wątku powodującego błąd, prawdopodobnie zmieniony na inny kod wyjątku.

Filozofia projektowania polega na tym, że VirtualAlloc zwróci zero (technicznie wskaźnik NULL) zamiast adresu, jeśli skończy się limit zatwierdzeń, i całkowicie uzasadnione jest oczekiwanie od programisty, że wie, że wywołanie VirtualAlloc może zakończyć się niepowodzeniem. Dlatego programiści powinni sprawdzić tę sprawę i zrobić coś rozsądnego w odpowiedzi (na przykład dać ci szansę na zapisanie pracy do tego momentu, a następnie zakończyć program „z wdziękiem”). (Programiści: Sprawdzasz, czy wskaźnik NULL zwraca zwrot z malloc, nowy itp., Tak? Więc dlaczego by tego nie zrobiłeś?)

Ale programiści nie powinni oczekiwać, że takie proste odniesienie do pamięci, takie jak

i = 0;             // initialize loop counter

może zawieść - nie, jeśli znajduje się w obszarze pomyślnie zatwierdzonej przestrzeni adresowej. (Lub zmapowana przestrzeń adresowa, jeśli o to chodzi.) Ale to może się zdarzyć, jeśli zastosowana zostanie filozofia „zezwól na nadmierne przydzielanie, niech odwołanie do pamięci nie powiedzie się”.

Niestety odwołanie do pamięci, takie jak w powyższym wierszu kodu, po prostu nie ma wygodnego sposobu na zwrócenie złego statusu! Po prostu powinny działać , podobnie jak dodawanie i odejmowanie. Jedynym sposobem zgłaszania takich awarii byłyby wyjątki. Aby je obsłużyć, programista musiałby owinąć cały program w moduł obsługi wyjątków. (spróbuj ... złapać i tak dalej.)

Można to zrobić ... Ale przewodnikowi trudno byłoby wiedzieć, jak „zrobić właściwą rzecz” w odpowiedzi na te wyjątki, ponieważ w kodzie byłoby tak wiele punktów, w których mogłyby powstać. (W szczególności mogą powstawać przy każdym odwołaniu do pamięci VirtualAlloc'd, do pamięci przydzielonej z malloc lub new ... oraz do wszystkich zmiennych lokalnych, ponieważ stos jest również VirtualAlloc.)

Krótko mówiąc, sprawienie, że program zawiedzie z wdziękiem w takich przypadkach, byłoby bardzo trudne.

Z drugiej strony dość łatwo jest sprawdzić zwrot wskaźnika NULL z VirtualAlloc (lub malloc lub nowy, jeśli chodzi o tę sprawę, chociaż nie są dokładnie takie same), a następnie zrobić coś rozsądnego ... na przykład nie próbować iść i rób cokolwiek to było, program potrzebował tej wirtualnej przestrzeni. I może zapytać użytkownika, czy chce jak dotąd zapisać swoją pracę. (To prawda, że ​​zbyt wiele aplikacji nie zadaje sobie trudu, by robić tak dużo.)

Inni użytkownicy zatwierdzenia

Nawiasem mówiąc, „limit zatwierdzania” nie jest zmniejszany przez różne alokacje systemu operacyjnego, takie jak pula stronicowana i niestronicowana, lista PFN itp .; są one po prostu obciążane, aby dokonać opłaty w momencie ich wystąpienia. Opłata za zatwierdzenie lub limit zatwierdzenia nie jest również zależna od pamięci RAM wideo, a nawet rozmiaru „okna” RAM pamięci wideo.

Sprawdź to sam

Możesz to wszystko zademonstrować za pomocą narzędzia testlimit ze strony SysInternals. Opcja -m przydzieli przydzieloną przestrzeń adresową, ale jej nie „dotknie”, więc nie spowoduje przydziału pamięci RAM. Podczas gdy opcja -d przydziela i odwołuje się do stron, powodując zarówno zwiększenie opłaty zatwierdzenia, jak i zmniejszenie dostępnej pamięci RAM.

Referencje

Elementy wewnętrzne systemu Windows autorstwa Russinovicha, Solomona i Ionescu. Istnieją nawet demonstracje pozwalające udowodnić wszystkie te punkty za pomocą narzędzia testlimit. Jednak muszę cię ostrzec, że jeśli uważasz, że to było długie, ostrzegaj: sam rozdział Mm ma 200 stron; powyższe jest BARDZO uproszczoną wersją. (Proszę również spojrzeć na sekcję „Podziękowania” we wstępie.)

Zobacz także dokumentację MSDN VirtualAlloc