W systemach Windows pojęcie "pamięci zadeklarowanej" (często spotykane jako commit) oznacza ilość pamięci, którą procesy i system zarezerwowały i dla której system musi mieć zapewnione "pokrycie" (backing) – czyli możliwość utrzymania jej w RAM albo w obszarze wymiany na dysku.
Limit pamięci zadeklarowanej (commit limit) nie jest równy samej pamięci RAM. Zwykle jest to wartość wynikająca z sumy zasobów, które mogą zostać użyte do podtrzymania tych rezerwacji, a kluczowym składnikiem zwiększającym limit jest plik stronicowania (pagefile, plik stron). Gdy plik stronicowania ma znaczący rozmiar, system może przyjąć większą liczbę deklaracji pamięci, nawet jeśli fizycznie zainstalowanej pamięci RAM jest mniej.
Dlatego odpowiedź "Pamięć pliku stron." jest poprawna: to plik stronicowania stanowi mechanizm, który pozwala podnieść limit zadeklarowanej pamięci ponad wielkość pamięci fizycznej.
Pozostałe odpowiedzi nie pasują do pytania:
- "Pamięć cache procesora." – cache (L1/L2/L3) jest bardzo szybka, ale ma małą pojemność i nie pełni roli "zapasowego magazynu" zwiększającego commit limit; nie jest też konfigurowana w systemie jako zasób dla pamięci zadeklarowanej.
- "Pamięć RAM." – RAM oczywiście wpływa na limit, ale pytanie dotyczy sytuacji, gdy limit jest większy niż zainstalowana pamięć fizyczna. Elementem, który umożliwia przekroczenie samej pojemności RAM, jest plik stronicowania.
- "Pamięć jądra." – to określenie odnosi się do obszarów pamięci używanych przez system (np. pule pamięci), ale nie jest mechanizmem, który "dopisuje" dodatkową pojemność do limitu deklaracji. Nadal bazuje na RAM i mechanizmach wymiany, a nie zastępuje pagefile jako źródła zwiększenia limitu.
W praktyce, gdy aplikacje zgłaszają błędy braku pamięci mimo wolnej pamięci RAM, warto sprawdzić parametry związane z commit oraz konfigurację pliku stronicowania. Zbyt mały lub wyłączony plik stron może obniżać commit limit i powodować problemy ze stabilnością aplikacji.