VS 2015 Enterprise - debugowanie i zwalnianie dynamicznej pamięci

Witam,
debugując swój program zauważyłem, że po zwolnieniu dynamicznie przydzielonej pamięci np.

Pamięć zarezerwowana przez program nie zmniejsza się, dlaczego? Coś źle robię?

niby jak chcesz mierzyc bajtowe zuzycie pamieci? wyjdz z zalozenia, ze ponizej kilobajta nie zauwazysz wachan w zużyciu pamieci przez aplikacje.

Zrobiłem test:

Cały czas pokazuje ~1MB

ss
http://iv.pl/images/63820353241492485266.jpg

Debugger VS ma kilka różnych usprawnień przy zarządzaniu pamięcią, np. u mnie po zwolnieniu pamięci i od razu alokowaniu innego obiektu ale o tym samym rozmiarze program "wsadzał" go w to przed chwilą zwolnione miejsce w pamięci gdy natomiast odpaliłem dokładnie tan sam program ale normalnie z folderu debug to już nowy obiekt był alokowany w innym miejscu. Spróbuj 1mb to też nie jest dużo. Spróbuj ok 1,5 gb zaalokować i wtedy zwolnić i zobacz co będzie.

Przy 423MB już było widać zwolnienie pamięci.

To ja może tylko dodam w ogólnym uproszczeniu, że to jak zachowuje się pamięć zależy od systemu operacyjnego i tego jaki algorytm wykonuje planista wykorzystania pamięci. Alokacje mogą alokować na zapas zaś dealokacje mogą być odkładane w czasie, mogą być też stosowane różne predykcje i inne cuda starające się eliminować fragmentacje pamięci czy migotanie stron.

Jeżeli program jest odpalany z poziomu VS to również jest kontrolowany (mniej lub bardziej) przez środowisko Visuala, które pośredniczy i wtrąca się pomiędzy aplikację a system w tym jak działa pamięć czy wątki.

To ja może tylko dodam w ogólnym uproszczeniu, że to jak zachowuje się pamięć zależy od systemu operacyjnego

Nie od systemu operacyjnego, tylko od alokatora (w sensie malloc i free), który jest zwyczajnym kodem trybu użytkownika i jeśli ten domyślny nam nie pasuje, to można sobie bez problemu użyć użyć w programie innego. Alokatory zwykle w minimalnym stopniu zależą od samego systemu operacyjnego, zazwyczaj potrzebują tylko odpowiedników mmap, munmap i kilku funkcji związanych z wątkami, głównie dotyczących TLS.

To alokator decyduje o tym, kiedy wolnych bloków ma za dużo i kiedy je zwrócić do systemu (przez munmap), z tego powodu inaczej będzie wyglądać ilość "zajętej" przez program pamięci, gdy alokatorem jest dlmalloc, inaczej, gdy to ptmalloc, inaczej dla jemalloc, inaczej dla windowsowego HeapAlloc itd.

W takim razie rozwiej moje dalsze wątpliwości i popraw mnie jeśli się mylę, bo może po prostu ktoś mnie oszukał :)

Za  oraz  prędzej czy później siedzą wywołania systemowe, które mogą elastycznie operować pamięcią dopóki jest to wizja spójna z punktu widzenia programu.

Na przykład, model pamięci dla Enea OSE będzie alokował bufor o wielkości przynajmniej takiej o jaką żąda użytkownik, czyli zwykle nieco większej. Nie będzie o tym decydować alokator ale sam kernel.

Co stoi na przeszkodzie aby za wywołaniami systemowi stał alokator plastrowy ograniczający prawdziwą alokację i dealokację pamięci? Aby stała za nimi inicjalizacja pamięci dopiero przy próbie odczytu/zapisu do danego bloku? Aby system przydzielał pewien spory kawałek pamięci a następnie przy kolejnych prośbach o pamięć informował o kolejnych kawałkach tortu?

Co z Singularity, który dla każdego procesu posiada oddzielny GC?

Czy można osądzić, że dany  na pewno alokuje pamięć a nie nieświadomie korzysta z jakiejś optymalizacji w systemie? Czy można osądzić, że system po danym  naprawdę zwolnił pamięć i przekazał ją do swoich zasobów zamiast zaryzykować i poczekać na jego ponowne użycie przez program?