OS

Go back

OS Review
Device Driver
NS Tools

Home
Papers
Daily Link

To Main

12. 메모리 관리 (Memory Management)

아,,, 이 얼마만이던가. 내가 써놓고서도 도데체 어디까지 썼는지를 잊어버리는 바람에 내가 내문서를 다운로드 받아서 확인했습니다. 그동안 처가댁 부모님들의 방문, 발더스게이트, 그리고 JMoview개발로 이어지는 사건들틈에서 이거 써야하는데,,,하는 마음속의 메아리를 외면하느라 아주 혼났네요. 역시 사람은 죄짓고 살면 안됩니다.

이번장에서의 메모리에 관한 논의는 연속할당(Contiguoud Allocation)으로 시작을 해볼까 합니다. 이거 읽으실분들, 나조차도 지금 기억이 가물가물한데, 한번 또는 아주 안읽은분들은 오죽하겄소,,,반드시 11장 메모리기초를 한번 더 읽어서 골을 싱싱한 상태로 리프레쉬 시켜준뒤에 읽기를 강력히 권고하오.

대개의 경우 메모리는 크게 두개의 부분(파티션)으로 나누어 쓰게 됩니다. 바로 오에스용과 유저 프로세스 용이죠. 이러한 전제하에서 다양한 메모리의 할당형태가 등장하게 되는데, 이중 가장 처음 등장했던것이 싱글파티션할당입니다. 싱글파티션 할당이라고 해서 위에서 말한 두개의 파티션이 한덩어리가 되서 존재하는것이 아니라, 각각이 하나의 덩어리로 존재하게 된다는 뜻이죠. 다음으로 등장한것이 멀티플파티션할당인데, 이는 메모리를 고정된! 사이즈로 조각조각파티션을 내게 됩니다. 그리고 각 파티션이 한개의 프로세스를 담게 만들어준다면 파티션의 갯수는 곧 멀티프로그래밍의 정도(degree)와 일치하게 되겠죠? 참고로 고정된 사이즈라함은 동일한! 사이즈들로 만든다는 뜻이 절대 아닙니다. 그 행간의미를 잘 음미해 보시길,,,:) 하여간, 이렇게 조각내어져서 메모리를 관리하게 된다면 비로서 메모리관리기법이라는 테크닉이 등장할 여지가 생기는데, 각 조각들의 크기(프로세스의 크기)가 다르니 만큼 메모리상에 구멍(hole)이 생기는 경우가 반드시 발생하고 맙니다. 즉, 프로세스를 담고있는 메모리 조각인 P1, P2, P3, 그리고 P4가 밑에서부터 차례로 메모리에 공존하다가 만일 P2와 P4가 자신의 프로세스를 마치게 된다면 씨피유는 P2와 P4를 스왑아웃시켜 버리죠. 자 그러면 뭐가 남습니까, 두개의 구멍이 휭~ 하니 남겠죠. 그 다음에 어떤 프로세스 P5가 메모리에 올라갈 일이 생겼다고 치죠. 이때 P5를 과연 어디에 올려야 좋을지를 결정하는 문제에는 다음과 같은 해결방안이 존재하게 됩니다.

First-fit: 말그대로 메모리를 밑에서 부터 스캐닝하다가 P5가 들어갈 공간 크기 이상을 만나면 그곳에 집어넣어 버립니다.
Best-fit: 이것은 P5가 자신의 크기와 가장 비슷한 구멍을 찾아서 들어가게 만드는 기법이죠. 이는 프로세스 하나 올릴때마다 전체 메모리를 스캐닝해야 하는 댓가를 지불하는 대신 결과적으로 가장 작은 크기의 구멍을 초래하게 되지요.
Worst-fit: 위의 Best-fit과 정 반대의 정책을 취합니다. 즉, 구멍중 가장 큰! 구멍을 찾아서 P5를 할당하죠. 이는 이럴경우 적당한 크기의 구멍이 결과적으로 남을테니 여기에 다음 올 프로세스가 쇽~ 들어갈지도 모른다는 가정을 하게 되는것입니다.

위의 세가지를 시뮬레이션해본결과 첫 두가지가 마지막 보다 더 시간과 스토리지 사용률면에서 좋은 결과를 보여줬다고 하네요. 그중에서도 첫번째가 으뜸 빠르겠죠?

현재까지 논의의 핵심이 되었던 그 "구멍"이 자꾸 발생됨으로써 메모리가 벌집처럼 조각조각나버리는 현상을 고상한 말로 프레그먼테이션이라고 합니다. 이 프레그먼테이션은 또 2가지 종류로 나뉘게 되는데 한가지는 외부 프레그멘테이션이죠. 이것은 위의 예에서 나왔던 현상을 말하게 되고요, 또하나인 내부 프레그먼테이션을 설명하면 다음과 같습니다. 만일 180,464 바이트짜리 구멍이 있고, 다음 올라올 프로세스의 크기가 180,462였다고 칩시다. 이것을 그대로 올리게 된다면 2바이트크기의 구멍이 존재하게 되는데,,,2바이트 크기의 구멍이 존재한다는 사실을 트래킹하는데 소요되는 오버헤드가 오히려 2바이트보다 더 크다는 사실에서 삶의 딜레마에 빠져버리게 되는거죠. 이런경우는 그냥 180,464전체를 다 그 프로세스에게 할당해 버림으로써 구멍을 없애는게 더욱 현명한 처사가 되겠죠. 이럴경우 2바이트는 외부적으로는 채워져 있지만 내부적으로는 사용이 되지 않고 있기 때문에 내부적 프레그먼테이션이라고 일컫게 되는것입니다.

외부 프레그먼테이션은 위에서 보여주듯이 멀티파티션할당시 반드시 발생할수 밖에는 없는 현상이지요. 이때 다음에 올라갈 프로세스가 구멍의 크기들의 총합보다는 작은데 각 구멍들보다는 큰경우 또한 반드시 발생할테고,,,이것을 해결하기 위하여 등장하는 테크닉이 바로 컴팩션입니다. 즉, 한 방향으로 할당된 메모리들을 밀어냄으로써 그 구멍들이 한곳에 모두 모여서 더욱 큰 구멍을 만들게 하는 기법이죠. 여기서 잠시 매킨토시 메모리관리를 언급하고 넘어가야 할듯해요.

짜잔~ 매킨토시 메모리 구조.
매킨토시는 나름대로 특유한 메모리 기법을 가지고 있습니다. 먼저 크게 두가지 파티션이 존재하죠. 바로 힙(heap)과 스택(stack)입니다. 스택과 힙은 마치 샌드위치의 빵처럼 프리메모리라는 햄을 감싸고 있는데, 통상적인 개념상 힙은 아랫쪽, 스택은 윗쪽입니다. 그중 68K맥의 경우는 스택위에 A5월드라는 레이어가 있어서 여기서 전역변수들을 저장해 두고는 했죠. 그러나 PPC로 넘어오면서 이 A5월드는 형장의 이슬로 사라집니다. A5라는 말 자체가 일단 68K 모토롤라 씨피유에 달려있던 레지스터 이름이니 만큼 사라져도 싸죠. 매킨토시 역시 크게 메모리를 시스템과 유저어플들이 사용하는 공간으로 나누어서 사용하는데 시스템은 맨 아랫쪽에서 밑에 시스템 글로벌 레이어와 바로 위에 시스템 힙을 얹혀놓고 있게되죠.

스택은 말그대로 카드묶음처럼 위에서 부터 차곡차곡 쌓아내려지거나 다시 하나하나 차례로 다시 사라지게 되는데 여기에서는 주로 로컬변수들을 담아두게 되지요. 로컬 변수는 함수내부에서 정의되었다가 함수의 호출이 끝나면서 졸지에 사라지는 변수들이라는 성격을 가지고 있다는 사실에서 a라는 함수가 b라는 함수를, b라는 함수가 또 ?c라는 함수를 호출하게 될경우 a->b->c순으로 메모리에 잡혔다가 사라질때는 c->b->a순으로 사라질테니 스택의 구조를 가지는것이 가장 적당하겠죠?

자, 이제서야 우리가 프로그래밍을 하면서 주목해야할 메모리의 왕자,,,힙이 등장합니다. 음,,,궁둥이왕자,,,하여간 스택은 자동적으로 크기가 늘었다 줄었다 거리면서 우리가 프로그래머 입장에서 컨트롤할수 있는 멋진 테크닉이 그리 많이 존재하지 않지만, 힙은 다릅니다. 힙은 일단 어플의 리소스, 실행코드들을 가지고 있기도 하지만, 다이내믹 메모리 할당이 일어나는 곳이기때문이죠. 눈치 빠른 분들,,,눈치채셨겠지만 그렇습니다!!! 여태 위에서 설명했던 프레그먼테이션이 일어나는 영역이 바로 이 힙입니다. 그래서 매킨토시에서 발생하는 컴팩션을 그래서 흔이들 힙컴팩션이라고 일컫고는 하지요. 힙에는 꽤 중요한 포인터가 인스톨되는데 그것들을 매스터 포인터(Master Pointer)라고 합니다. 매스터 포인터는 언제나 그 위치가 고정적이라는 특징에 주목하여 힙에서 일어나는 큰 메모리 할당들을 우리는 매스터 포인터를 다시 포인트해주는 핸들!이라는 데이터 타입을 이용하게 되는것이죠. 또한 매스터 포인터 자체는 고정적일지라도 그것이 가리키고 있는 힙에 할당된 메모리 블록들은 메모리 메니져에 의해서 주기적으로 일어나는 힙컴팩션에 의해 그 위치가 쥐도새도 모르게 밀려버리는 현상이 발생할수 있기때문에~ 우리가 핸들을 사용할때에는 종종 HLock()과 HUnlock()을 이용하여 컴팩션이 일어나지 못하도록 메모리 메니져를 말리게 되는겁미다. 핸들,,,이거 정말 좋은 겁미다.

맥오에스, 여러가지면에서 참으로 훌륭한 오에스이지만, 또 막상 이런 결정적인 오에스 기술이 등장할때는 꼬리를 살며시,,,내릴수 밖에 없는 이유가 또 여기서 한가지 등장하게 되요. 맥 어플들은 자신이 처음 할당할 공간의 크기를 지정해놓고 메모리를 점유하게 되지요. 하지만, 윈도우즈의 경우는 그런 세팅을 해주는곳을 눈씻고 찾아봐도 찾을수가 없을겁니다. 바로 페이징기술을 이용하기 때문이죠. 이론적으로 윈도우즈의 각 어플들은 자신에게 2GByte까지의 메모리를 할당할수 있게 된답니다.

그렇다면 그 좋은 페이징 기법이란 무엇인지 한번 살펴볼까요? 먼저 페이징 기법은 멀티플파티션할당을 하되 각 조각들을 프로세스 단위가 아닌 동일한! 크기로 잘라서 메모리에 할당하게 되고요, 이때의 크기를 우리는 페이지(pages)라고 부르게 됩니다. 페이징 기법은 하드웨어의 지원을 필수로 하고, 페이지 테이블이라는 테이블로 논리메모리와 물리메모리사이의 일대일대응관계를 규정해놓죠. 즉, 물리메모리사이에서는 페이지0다음에 페이지3이오고, 한참 빈공간뒤에 다시 페이지2가 할당되어있을지라도 논리메모리상으로는 페이지 0, 1, 2가 아주 깔끔하게 연결되어있게됩니다. 그럼 페이지 메모리기법의 가장 큰 특징은 무엇일까요? 힌트는 바로 동일한 페이지 사이즈입니다. 답은바로,,,외부프레그먼테이션이 절대로 일어나지 않는다는 것이죠. 마치 씨디 데크처럼 그냥 그때그때 필요하면 들어갈 규격화된 구멍이 존재할뿐, 절대로 외부적으로 메모리의 사이즈가 맞지 않아서 할당을 못하는 일은 발생하지 않게 되는겁니다. 허나! 내부 프레그먼테이션은 반드시 존재하게 됩니다. 왜냐하면 하나의 프로세스를 자잘하게 페이지 단위로 자르니 만큼, 모든 프로세스의 크기가 다를진데 페이지 단위로 딱~ 맞아 떨어질리가 없기 때문이죠. 고로 페이징 기법에있어서관심사중 하는 바로 페이지 크기가 되겠죠. 오늘날에 주로 쓰이는 페이지의 크기는 2k또는 4k 바이트라고 하네요.

페이지라는 말은 논리주소상에서의 메모리 조각이고 물리주소상에서는 프레임(frame)이라는 말을 사용하지요. 프레임또한 어떤것이 현재 할당되어있고, 어떤것이 현재 비어있는지를 트래킹하기 위하여 프레임테이블을 또 필요로 하고요. 이래저래 조금 복잡한 기술이되어버립니다. 페이징 기법의 특징 또한가지는 아까 말한 논리주소와 물리주소의 철저한 격리입니다. 논리주소는 페이지테이블로 관리하게 되면서, 참으로 재미있는 기술이 가능해 집니다. 바로 멀티레벨 페이지으로써 페이지 테이블이 주소가 아닌 또다른 페이지 테이블을 포인팅 하도록 만드는 기법이죠. 이것이 두번 세번 반복하게 함으로써 결국엔 2의 64승 바이트정도의 논리적 메모리를 한개의 어플이 점유해버리는 상황도 가능해지게 되는 것이죠. 페이징기법에서의 메모리 보호를 위한 몇가지 테크닉이 존재하지만, 이것들은 나중에 여러분들이 관심있을때 읽어주시기 바래요.

이번장의 마지막은 세그멘테이션(segmentation)으로 마무리를 질까 합니다. 세그멘테이션은 그동안 논의되었던 메모리 기법들보다 한층 고차원적인 기법이됩니다. 이것은 메모리를 조각냄에 있어서 단순한 프로세스나 코드의 크기등을 기준으로 하는 것이 아니라 마치 클래스라이브러리가 클래스로 나뉘듯 추상적인 개념이 도입되죠. 예를 들어서 한개의 어플을 서브루틴, 스택, 심볼테이블, 그리고 메인등으로 나누게 되요. 이 기법의 장점은 어떤 사람이 에디터를 사용하기 위하여 서버에서 어플을 메모리에 할당했다고 합시다. 세그멘테이션 기법의 경우 이때 메모리에는 에디터 세그멘트와 데이터 세그멘트가 올라오게 되죠. 같은 시간, 또 다른 사람이 원격으로 서버에 접속해서 같은 에디터를 띄울경우, 이때는 데이터 세그멘트만 띄우지게 되고 그 둘은 에디터 세그멘트를 공유하게 됩니다. 당연한 결과로 세그멘테이션은 다시 외부 프레그먼테이션을 유발하게 되기에 급기야는 인간들이 세그멘테이션을 페이징기술과 함께 사용하는 아주 복잡한 궁극의 기법을 구사하게 됩니다.

그 궁극의 기법은, 놀랍게도, 인텔의 80386이 사용하고 있었다고 합니다. 또한 멀틱스(MULTICS)라는 별로 많이 쓰이지 않는 이상한 시스템의 예가 있는데, 이녀석은 논리 어드레스가 일단 세그멘테이션을 위한 페이지테이블을 참조하고, 그 테이블은 다시 세그멘테이션 테이블의 페이지를, 그페이지는 다시 세그멘테이션을 위한 페이지 테이블을, 그리고 이놈이 다시 세그멘테이션의 페이지를 참조함으로써 (4번의 얄딱꾸리한 포인터 연산입니다) 논리주소와 물리주소를 연결하게 됩니다. 몬소리인지 알겠는분은 당장 하던일 때려치고 오에스 연구해서 성공하시길 강력 권장합니다.

이로써 메모리의 2/3를 끝마쳤네요. 다음장에서는 드디어 버쳐메모리로만 한장을 통채로 다룰 예정입니다. 우리는 버쳐메모리가 느리다고 그냥 얼마안되는 램을 헐값에 사서 껴놓고 아무 생각없이 "에잇! 버쳐 꺼져버려라~" 이러지만,,,이것은 위에서 언급한 모든 메모리 기법들을 집약한 메모리관리의 꽃이며, 이걸 연구하던 사람들의 노고를 생각한다면 결코 그렇게 무심하게 꺼버릴수 없을겁니다. 이거정말 이짓으로 밥먹고 살기가 점점 어려워짐을 절감합니다.

-duffer 경준 (http://vorlon.cwru.edu/~kxm73)