malloc/new jak działa

Cześć ;)

1. Skupmy się na malloc, bo intuicja mi podpowiada, że new działa podonie do malloc, mam rację?
2. Jak to działa. To znaczy chodzi mi o to, że wiadomo, że program sam sobie nie może wziąć pamięci z kopca. Jest ona przydzielana przez system operacyjny.
   Cała wątpliwość wzięła się stąd, że przeczytałem, że VirtualAlloc jest powolniejszy niż malloc(). VirtualAlloc to funkcja alokująca udostępniona przez API Windowsa.
   No jak to wolniejsze? No jak to malloc szybsze? Przecież malloc musi poprosić Windows o to, żeby mógł dać pamięć.
   No chyba, że VirtualAlloc jest stosowany do innych celów ( ale w artykule, który czytam wynika, że tak nie jest ). Jeżeli jednak, w takim razie jak to działa?

1. T* t = new T(foo) może być jako zaimplementowane jako

void* tmp = ::operator new(sizeof(T))
new (tmp) T(foo)

gdzie ::operator new działa podobnie jak malloc - przydziela odpowiednią ilość odpowiednio zalignowanej pamięci.

1. malloc nie woła VirtualAlloc, czy innego systemowego API za każdym razem. Żąda rzadziej, a więcej, a potem wydziela programowi wedle potrzeb (t.j. wywołań). Przy czym nie jest to zdefiniowane przez standard, jest to bardzo zależne od implementacji.

W wielkim uproszczeniu:

• funkcja malloc wywołuje GlobalAlloc przydzielając bardzo duży obszar ale zwraca małą część tego obszaru
• przy kolejnym wywołaniu malloc już nie wywoła GlobalAlloc dopóki nie "rozda" tego dużego obszaru.

• funkcja malloc wywołuje GlobalAlloc przydzielając bardzo duży obszar ale zwraca małą część tego obszaru

Jak się mogę o tym przekonać? :)

Debuger do rąk i ...

...i sprawdzić, że przy wywołaniu malloc nie zawsze jest wołana API?

Pod linuxem masz takie narzędzie jak strace, moze pod windowsa też coś jest.

Polecam jednak zrobić gcc -O0 bo obawiam się że w tym przypadku kompilator zwyczajnie zoptymalizował kod :P Zerkaj zawsze na gcc -S żeby się upewnić co realnie uruchamiasz...

Co ciekawe, nic nie zoptymalizował:
bo zarówno przy -o0, jak i bez tego kod assemblerowy wygląda tak samo. Co więcej, mam w assemblerze mam dwa wywołania malloc! Czyli jak to w końcu jest?
main:

.LFB7:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$5000, %edi
	call	malloc
	movl	$5000, %edi
	call	malloc
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

Dlaczego tutaj nie są wciskane argumenty na stos? W książce czytałem, że przed wywołaniem funkcji zachodzi PUSHowanie argumentów na stos, a potem CALL. Tu tak nie jest.

Oczywiście że są dwa wywołania, śledź co się dzieje wewnątrz.

wewnątrz wywołania? Jak mogę to zrobić?

Step In

ok

Zobaczmy co robi new pod Visual C++ 2010 (czytać od dołu):

Wygląda na to, że operator new() wywołuje po prostu malloc. Wystarczy więc tylko sprawdzić co robi malloc().

Mamy tu kilka dziwnych zagnieżdzonych wywołań (są tylko w wersji Debug, w Release nie ma tego nh_malloc_dbg) ale widzimy wywołanie funkcji systemowej RtlAllocateHeap.
Czyli Visual pomija funkcje WinAPI VirtualAlloc/GlobalAlloc/LocalAlloc i dobiera się bezpośrednio do jądra systemowego. No coż: co wolno wojewodzie (tutaj: kompilatorowi Microsoftu)...

Prześledziłem jądro kawałek dalej, i znalazłem funkcję o nazwie RtlpUpdateIndexRemoveBlock. Być może odpowiada ona za usunięcie bloku pamięci z listy wolnych bloków.
Bo tym jest właściwie alokacja — oznaczeniem w „jakiś” sposób, które obszary pamięci są zajęte, a które wolne. Pamięć przecież istnieje cały czas.

Nie udało mi się zauważyć sytuacji alokacji „wewnętrznej” w mallocu; zawsze jest wykonywane RtlAllocateHeap nawet przy następujących po sobie new char[1]. Być może Visual tak ma.

dzięki, dzięki, dzięki! :)