alloc계열 함수의 오버헤드???

자료구조에서나오는 heap과 메모리 종류로서의 heap은 사실.. 거리가 좀 있는 개념이라,

메모리에서의 heap이 구현방식이 b-tree 이거나 linked list 로 될 수 있다는 말은 옳습니다.

이루 말할 수 없는 차이지요. stack 상에서 메모리 확보하는 것은 거의 machine어로 한 명령입니다. 단지 스택포인터에 값을 더하는 것으로만으로 모든것이 끝나지요.

하지만 malloc 은 커널로부터 할당받은 메모리가 부족한지도 봐야하고,
부족하면 더 요청해야하며, 할당받은 공간을 기존 조각들과 이어놓아야하는 등
수많은 작업을 하게 됩니다.

glibc 같은 소스를 받아서 malloc 부분을 열어보시면 많이 도움이 되실 듯합니다.

프로그램 실행시 프로그램 기본 할당 영역 외에 OS에서 추가로 할당해 주는
영역을 가리키는 heap (보통 malloc()류의 함수로 할당받죠)과
자료구조책에 나오는 heap이라고 불리는 괴짜 트리를 헷갈린거 아니에요?

용어가 같아서 그렇지 둘은 엄연히 다릅니다.

제가 heap을 링크드 리스트로 구현했다는 말은 malloc()의 블럭 관리를 링크드
리스트로 한다는 말이죠. 근데 glibc 소스 주석문 들춰보면 링크드 리스트로 힙을 관리하는거
같더군요. (이거 갠적으로 상당히 맘에 안들긴 하지만)

오버헤드 비교대상이라기 보다.. malloc은 동적 멤생성이란 잇점으로 봐야할것은같은디..

그래두 비교해보면.

1. "char buf[100];"이 현재 stack page안에서 만들수 있는경우.
- 이럴경우는 당근 "char buf[100]" 이넘이 훨빠르겠죠. 빠르다기 보다
오버헤드가 없죠.
2. "char buf[100];"가 현재 stack page를 넘어서는 경우.
- 이럴경우는 kernel에서 get_freepage덩가? 하여튼 이넘 불러서 새로운
page를 받고 0으로 채우고, process에게 할당해줘야 합니다.
- malloc은 실제 물리적은 메모리를 할당하진 않지만, page table을 설정
해 줘야 하고, process의 heap영역관련 struct를 손봐줘야 합니다.
- 이럴경우는 아무래두 malloc이 쬐끔 빠르지 않을까 생각됩니다. getfreepage가 생각보다 오버헤드가 크죠, 물리적인 메모리 할당할려면 kernel memory management관련 struct도 건드리니깐...--;

이상 제생각 이었습니다.

스택크기를 미리 좀 늘려주면 위와 같은 사항은 거의 나오지 않습니다만은 --;

그리고 재귀 호출이 없는한....대다수의 스텍재할당은 컴파일타임때 알수 있습니다

///-----추가
제가 알기론.... 동적 할당은 커널 레벨까지 가지 않습니다--;

훔.. 먼가 잘못알고 계시는거 아닌가요?
1. stack 재할당
stack크기는 물론, 컴파일 할때 알 수있지요 하지만 elf file에 그내용이 들어가지 않습니다. 한page가 넘을때마다 page_fault가 뜨고 그때 재할당하는 겁니다. stack크기를 늘려준다 하더라도 생길 수도 있는문제지요.

2. dynamic memory allocation
하하하 웃기네요. kernel level까지 가지 않고 어떻게 동적할당을 할 수 있죠?
malloc호출하면 struct vm_area_struct mmap을 조절해야 합니다.
이건 process의 page_table을 재조정 한다는 거죠. 물론 실제로 memory를 할당하진 않고, 이영역의 memory를 access할때 page_fault가 뜨고 실제로 메모리를 할당하지요.

이과정을 kernel level까지 가지 않고 할 수 있다니 참으로 대단하십니다. 그려..