Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

VS 2015 Enterprise - debugowanie i zwalnianie dynamicznej pamięci

Ostatnio zmodyfikowano 2015-08-05 19:19
Autor Wiadomość
fokusx
Temat założony przez niniejszego użytkownika
VS 2015 Enterprise - debugowanie i zwalnianie dynamicznej pamięci
» 2015-08-01 23:30:57
Witam,
debugując swój program zauważyłem, że po zwolnieniu dynamicznie przydzielonej pamięci np.
C/C++
int ** tmp;
tmp = new int *[ 2 ];
tmp[ 1 ] = new int[ 2 ];

tmp[ 1 ][ 0 ] = 3;
tmp[ 1 ][ 1 ] = 3;

tmp[ 0 ] = new int;

* tmp[ 0 ] = 5;

system( "pause" );
delete[] tmp[ 1 ];
delete tmp[ 0 ];
system( "pause" );
delete[] tmp;
system( "pause" );

Pamięć zarezerwowana przez program nie zmniejsza się, dlaczego? Coś źle robię?
P-135592
DejaVu
» 2015-08-02 10:29:02
niby jak chcesz mierzyc bajtowe zuzycie pamieci? wyjdz z zalozenia, ze ponizej kilobajta nie zauwazysz wachan w zużyciu pamieci przez aplikacje.
P-135598
fokusx
Temat założony przez niniejszego użytkownika
» 2015-08-02 12:51:26
Zrobiłem test:
C/C++
int * tmp;
tmp = new int[ 10000 ];
for( unsigned i = 0; i < 10000; i++ )
     tmp[ i ] = i;

system( "pause" );

delete[] tmp;
system( "pause" );

Cały czas pokazuje ~1MB

ss
http://iv.pl/images/63820353241492485266.jpg
P-135605
michal11
» 2015-08-02 13:56:37
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.
P-135608
fokusx
Temat założony przez niniejszego użytkownika
» 2015-08-02 14:45:49
Przy 423MB już było widać zwolnienie pamięci.
P-135610
akwes
» 2015-08-02 19:15:34
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.
P-135612
Elaine
» 2015-08-03 05:47:12
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.
P-135637
akwes
» 2015-08-05 19:19:47
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
malloc
 oraz
free
 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
malloc
 na pewno alokuje pamięć a nie nieświadomie korzysta z jakiejś optymalizacji w systemie? Czy można osądzić, że system po danym
free
 naprawdę zwolnił pamięć i przekazał ją do swoich zasobów zamiast zaryzykować i poczekać na jego ponowne użycie przez program?

P-135801
« 1 »
  Strona 1 z 1