[C,C++] memory fragmentation

memory fragmentation

메모리 단편화와 관련한 이야기를 해볼까 한다.. 

우리는 우리의 프로그램을 사용하는 사람들의 PC가 슈퍼컴퓨터가 아닌 것을 알고 있다.

그렇지만, 우리는 메모리를 효율적으로 사용하기 위해서 얼마나 고민하고 있을까?

나는 될 수 있다면 new 키워드를 사용하지 않으려고 노력한다.

Native 개발자가 Low 레벨 메모리 접근을 꺼리는 이유는 여러 가지다.

나의 경우는 멀티스레드, 멀티코어 환경에서 안전성을 보장받지 못한다는 점과(그건 뭐.. 대부분 그렇긴 한데..)

경험상 메모리 할당의 남발이 메모리 단편화의 문제를 만들고,

결국 성능을 저하하는 원인이 될 수 있기 때문이다.

메모리 생명주기를 알 수 없는 런타임 메모리 할당이 스택 될 수 없고,

필연적으로 단편화가 발생할 것이라는 걱정이 있다.

"오래 쓰면 느려져요"라거나, "동시에 여러 개 켜면, 버벅거려요" 라는 것은

대부분 이런 문제가 아닐까 싶다.

(다른 원인으로, 코어를 한정해두면, 동일 제품이 여러 개 켜질 때, 병목이 발생할수도 있다.)

 

단순히 malloc과 free 메모리 탐색, 병합이 느리지는 않다.

malloc 과정에서 연속된 메모리 공간을 찾는 과정은 느리지 않다고 한다.

작은 블록들은 크기 별로 linked-list 형태로 관리되어 단순 상수 시간 검색으로 찾을 수 있다고 하고,

그 밖에 페이지 단위보다 작은 크기의 메모리 블록들은 O(m) 시간 탐색 가능한 trie 형태로 관리되며

페이지 단위보다 크면 운영체제 환경에 따라 빠른 접근 방법이 존재한다(virtualalloc).

또한, 메모리가 free 되면 연속될 수 있는 경우에는 병합되기 때문에 단편화의 문제가 줄어든다고 한다.

 

그러나 모든 free 메모리가 연속되어 병합될 수 없고

결국 사용할 수 없는 작은 블록들은 메모리 할당자에게 무시될 수 있다.

여기서 내부 단편화의 경우(주소 크기 단위로 할당하여 사용되지 않는 공간)는 메모리 할당에 관여하는 

개발자의 꼼꼼함이 필요하지만, 

외부 단편화의 경우(할당된 메모리 블록사이의 free블록)는 stress 테스트나 분석 도구를 활용하여

일정 기준 이상의 제품 상태를 만족시킬 때까지 테스트를 해야 한다.

프로그램이 런타임에 사용하는 In-Memory DB 크기를 알 수 있다면,

혹은 그려질 그래픽 메모리를 파악할 수 있다면, 메모리 풀을 만들어서 직접 관리하는 방법도

메모리 단편화를 줄일 방법이다. 이는 어차피 잡혀야 하는 메모리를 alloc, free를 

반복하여 관리하지 않고 큰 블록하나를 관리하고자 함인데, 프로그램이 실행하는 시점에,

시스템 상태에 따라서 동작하는 내부 옵션화로 접근할 수 있겠다.

 

추가로 힙 메모리 사용 시에 문제를 하나.. 언급하고자 한다.

바로, heap overflow vulnerability 문제이다.

주로 버퍼 오버플로우(buffer overflow)와 버퍼 오버런(buffer overrun)을 말한다.

heap 메모리 할당으로 기존 heap을 덮을 가능성이 있다는 말이다.

(heap은 높은 주소로 영역을 넓힌다. 주소 영역 상위에 주요 메모리가 있다면 덮어질 수 있다.)

제품 개발자가 이런 실수를 한다면, 프로그램은 단순히 죽을 것이고, 사용자에게 불편을 준다.

회사의 입장에서는 제품의 안정성으로 매출에 영향을 받을 수 있다는 점도 그렇지만,

Crack의 문제가 더욱 골치 아프다. 보통은 프로그램의 DB 등을 부숴버리기 위하여 취약점을 공격하지는 않는다.

프로그램이 주는 이익을 취하기 위해서 불필요한 결함을 만들 필요는 없기 때문이다.

보통은 사용자 권한이나, 제품 인증을 위한 메모리나, 스택을 지워버린다.

(실제로 dll.dll이라는 이상한 dll이 권한 인증 단계의 스택을 무시하도록 한 경우를 보았다...)

 

 

malloc performence

http://3dmpengines.tistory.com/1408

 

memory fragmentation

http://acezero79.blogspot.kr/2008/02/electronics-design-strategy-news.html

 

trie 

https://namu.wiki/w/%ED%8A%B8%EB%9D%BC%EC%9D%B4

 

heap overflow vulnerability

buffer overflow & buffer overrun

https://ko.wikipedia.org/wiki/%EB%B2%84%ED%8D%BC_%EC%98%A4%EB%B2%84%ED%94%8C%EB%A1%9C

http://janghw.tistory.com/entry/Heap-Buffer-Overflow

 

false sharing

http://www.smallake.kr/?p=2271