|
Go back OS Review Device Driver NS Tools Home Papers Daily Link To Main |
11. 메모리관리의 기초 (Basics of Memory Management)
지난 내용을 통하여 우리는 씨피유 스케줄링을 통하여 씨피유의 활용도를 높이고, 씨피유를 포함한 여러 리소스들을 보다 효과적으로 공유함으로써 시스템의 속도 및 유저에 대한 반응을 전반적으로 향상 시킨다는 사실을 알수 있었죠. 여기에는 아주 중요했지만, 명확히 언급되지 않은 전제가 한가지 있습니다. 바로 여러 프로세스들이 각자 자아실현을 하는 공간인 메모리에 대한 오에스의 관리입니다. 본장에서는 여러가지 메모리 관리 기법들과 그에 대응되는 알고리즘들을 설명하기 위한 기초 어휘들과 기초 지식이등장합니다. 아, 수도코드(Pseudo-code)는 앞으로는 본 스터디가 끝나기 전까지는 절대 출현하지 않으니만큼, 긴장 푸시고, 편안한 마음으로 나머지 논의들을 즐겨주시기 바래요. 본 장을 들어가기에 앞서서 한가지 주지할 사실은 대부분의 메모리 관리 기법들은 시스템의 하드웨어적 디자인에 많이 좌우된다는 사실이죠. 즉 하드웨어가 지원을 해야한다는 뜻입니다. 그러면 어떠한 방법으로 오에스는 메모리를 관리하는지 한번 본격적으로 살펴볼까요? 아, 그리고 이것은 일종의 저만의 주관일수 있는데, 메모리 관리를 논한다 함은 메모리 자체만의 효과적 이용 보다는 백킹스토어(backing store)라 불리는 하드드라이브 같은 보조기억장치와 주기억장치인 메모리 사이의 미묘한 관계를 잘 활용하는것을 뜻하는듯 싶습니다. 그 둘은 사실 본질적으로는 용량과 속도만이 다를뿐 뭔가를 저장 한다는 측면에서는 하등 다를바가 없거든요. 메모리를 단순화시킨 시각에서 바라볼때에는 워드(word)또는 바이트(byte)단위의 길죽한 일차원 배열입니다. 메모리와 씨피유가 어떻게 상호작용하는지 한번 살펴보면, 씨피유는 프로그램 카운터(Program Counter:다음 실행할 명령이 들어있는 메모리의 주소)를 참조해서 명령을 띄우고(fetch), 그 명령이 수행되면서 특정한 주소의 메모리 공간에서의 로딩, 또는 저장등을 추가적!으로 발생시키게 됩니다(프로그램 카운터도 이때 업데이트 되겠죠). 여기서 우리는 한가지 사실을 알수 있는데, 메모리의 시각에서는 호출되는 자신의 주소값들에 대한 일련의 흐름(stream)만이 인식될뿐, 어떠한 원리로 해당 주소값들이 생성되고, 씨피유가 메모리를 호출할때마다 내보내는 명령어나 데이터값을 생성하는지등에는 전혀 무지하다는 점이죠. 고로 앞으로 우리가 메모리 관리를 논의함에 있어서 '어떻게 메모리 주소값들이 알고리즘에서 생성되는가?'라는 황당한 질문 보다는 해당 알고리즘에서 '어떠한 순서!로 메모리 주소값을 생성시키는가'가 라는 구체적인 질문이 바로 앞으로 펼쳐질 논의의 핵심이 되겄습니다. 메모리를 논함에있어서 먼저 바인딩(binding)이라는 개념을 제일 먼저 짚고 넘어갈 필요가 있있어요. 유저 프로그램은 일단 하드 디스크 안에 바이너리 파일로 존재를 하지요. 이것이 실행이 되기 위해서는 반드시 메모리상에 그것도 프로세스 내부로 로딩이 되어야만 합니다. 우리가 특정 어플을 실행시키기 위하여 더블클릭 하는순간, 코드가 메모리에 로딩이 되기 위해서는 프로그램내부에 존재하던 심볼주소값(symbolic address)들이 실제로 할당이 가능한 재할당가능주소(relocatable address)값들로 주르륵~ 변환 되어야 하겠죠. 바로 이러한 과정을 우리는 바인딩이라고 일컫는 것입니다. 바인딩은 그 행동이 취해지는 시점에 따라서 몇가지로 나뉠 수 있습니다. 첫째로는 컴파일타임(compile time)으로써 소스코드를 컴파일할때 이미 어떤 변수 어떤 명령어가 구체적으로 어떤 절대적(absolute) 메모리에 할당되는지가 결정되죠. 640k정도의 작은 메모리를 효과적으로 이용해야하는 MS-DOS의 *.com파일들이 이에 해당이 됩니다. 두번째로 로드타임(load time)입니다. 이경우 최종 바인딩은 프로그램이 로드되는 순간 결정되며 시작주소값(starting address)이 바뀔때, 나머지 주소값들은 자동적으로 주르르 밀려서 바인딩 되겠죠. 마지막으로 엑세큐션타임(exectution time)인데, 이것은 정말 막강한 바인딩 방법으로써, 프로세스 단위로 필요할때마다 그 내용이 런타임중 바인딩이 되지요. 하드웨어적 지원을 필수로 요구합니다. 바인딩과는 별개로 다이내믹로딩(dynamic loading)을 이해할 필요가 있군요. 다이내믹로딩은 루틴!단위로 해당 루틴이 호출되기 전 순간에조차 그 루틴이 메모리가 아닌 디스크에서 깨비작거리게 만드는 기법입니다. 이 기법의 장점은 사용되지 않는 루틴들은 결코 메모리를 점유하지 않음으로써 결국 로딩조차 되지 않게 된다는 사실이며, 이 기법의 특징은 특별히 오에스의 특별한 지원을 필요로 하지 않고 프로그래머의 재량에 따라 구현이 가능하다는 사실이죠. 이 기법은 주로 드물게 발생하는 에러처리 루틴따위에 적용하면 좋다고 하네요. 바인딩은 결국 코드가 올려질 물리적인 메모리 주소값을 결정!하는 과정이고, 로딩은 결정된 물리적인 주소값에 코드를 할당시키는 행위!라고 할수 있겠습니다. 또, 다이내믹링킹(dynamic linking)이라는것이 등장하는데, 윈도우즈의 *.dll(dinamic linked library)파일들이 바로 이 다이내믹링킹 기법의 사생아 들입니다. 대부분의 오에스들은 스태틱링킹(static linking)이라는 랭귀지의 라이브러리들이 컴파일시 합체되는 기법을 사용하죠. 그런데 다이내믹링킹은 컴파일과정중 링크과정이 바로 런타임에 일어난다는 차이점을 가지고 있습니다. 즉, 각 dll은 이미 컴파일된 라이브러리들인것입니다. 이기법은 주로 시스템 라이브러리들에 적용하면 효과를 본다고 하는데, 원리는 다음과 같습니다. 컴파일시 스텁(stub)이라는 간단한 표적같은것이 해당 라이브러리 루틴의 참조(reference) 대신 달려있다가(해당 루틴을 포인터를 이용해서 콜하는듯 싶군요) 런타임시 해당 루틴이 불리면 그 스텁은 자신을 그 루틴이 들어있는 구체적 주소값과 바꿔치기 해버립니다. 한번 이상 루틴이 불리게 되면 전에 스텁이 있었다는 사실조차 잊고 짜연스럽게 한몸이 되는것이죠. 다이내믹 로딩과는 달리(본 절에서는 링킹입니다) 이 기법은 만일 각 프로세스가 서로 프로텍션(proctection)을 걸고 있다면 오에스만이 그들 사이의 중재자가 되어줄수 있으므로 오에스의 도움을 필수로 합니다. 이방법이 제대로만 사용되면 정말 강력함을 발휘하는데, 각 프로세스는 라이브러리 루틴을 각자의 메모리에 복사하지 않은채 단 한개의 원본을 사용하게 됨으로써 메모리를 절감하고, 컴파일된 바이너리코드 또한 언제 쓰일지도 모르는 라이브러리 코드들을 내부에 포함하고 있지 않기에 날씬해지게 됩니다. 일석이조의 효과이죠. 허나, 현재 윈도우즈에서 사용되고 있는 꼴을 보고있노라면, 한개의 어플이 인스톨될때마다 혹시나 하는 마음에 너도나도 dll파일들을 깔다보니 dll 개판천지가 되어버리는 경향이 있는듯 하더군요. 그래도 M$제품군 사이에서는 꽤 효과적으로 쓰이는듯 싶습니다. 정말 수많은 어휘들이 등장하는군요! 이번에는 오버레이(Overlay)라는 기법을 알필요가 있는데, 아주 고전적이지만 정말 유용했던 기법이랍니다. 한 프로그램이 a, b, c, 그리고 d라는 바이너리로 이루어졌다고 했을때, 만일 c와 d가 각각 심볼테이블(symbol table)과 공통루틴(common routine)등과 같다면, 우리는 제일먼저 a, c, d를 메모리에 로딩해서 쓰다가 나중에 b가 필요할때 비로서 a대신 b를 샥~ 바꿔치기 해주는 기법입니다. 실제적으로 이 기법을 적용할때에는 e라는 상대적으로 아주 작은 메모리를 차지하는 오버레이 드라이버(overlay driver)를 만들어서 사용하게 되지요. 오버레이 드라이버가 상황에 맞춰서 a 또는 b를 메모리에 올렸다 내렸다 해주는 중재자 역할을 수행하게 됩니다. 이 기법은 어떻게 보면 앞으로 소개될 페이징이나 버츄어메모리 기법과 비슷해 보일수 있으나 그건 착각입니다. 본 기법은 만들고자 하는 프로그램의 깊은 이해를 먼저 필요로 했기에 꽤 난해한 기법이기도 했거든요(옛날에 한딱깔이 한다는 프로그래머들이 이 기법을 애용했죠). 바로 이점이 후자들과의 가장 큰 차이점입니다. 후자들은 어디까지나 현대적인 오에스 차원에서 지원해주는 기법이니까요. 씨피유에서 생성되는 메모리의 주소값을 우리는 앞으로 논리주소값(logical address)이라고 하고, 실제로 메모리에 의해서 인식되는 메모리의 주소값을 물리주소값(phisical address)이라고 할것입니다. 초반에 언급되었던 바인딩중 컴파일타임 바인딩과 로드타임 바인딩 이 두가지는 논리주소값과 물리주소값이 일치합니다. 허나, 엑세큐션타임 바인딩은 그 둘이 다르죠. 이때의 논리주소값을 바로 버쳐주소값(virtual address)이라고 하게 됩니다. 이경우, 그 둘의 주소값이 다르려면 런타임 맵핑이 둘 사이에서는 반드시 일어나야 하겠죠? 바로 그 맵핑을 수행해 주는 하드웨어 유닛이 바로 MMU(Memory Management Unit)입니다. 모토롤라 씨피유중 68030이하를 사용하던 매킨토시 기종인 LC나 클래식 등에서 앞으로 설명될 버쳐메모리(virtual memory)를 사용할수 없었던 이유가 바로 여기에 있어요. MMU내부의 메모리프로텍션에 등장했던 베이스레지스터(base register)가 이제부터는 리로케이션레지스터(relocation register)라고 불리게 되는데, 여기에는 일정한 정수값이 들어가 있어서 논리주소값과 물리주소값사이의 짝짓기를 '덧셈'으로 수행해주게 됩니다. 예를들어, 논리 주소값이 346이고, 리로케이션레지스터값이 14000이라면 물리주소는 346+14000=14346이라는 값으로 계산되는 식이죠. 당연히 논리주소값의 347는 물리주소값의 14347에 대응되게 됩니다. 이때 유저 프로그램은 물리주소값으로 자신의 논리주소가 변환된다는 사실조차 인식을 못하며, 모든 물리적인 메모리 할당은 오에스와 MMU사이의 농간으로 이루어집니다. 이 변환은 매번 메모리를 액세스할때마다 일어나는 필수불가결한 변환이기에 하드웨어적으로 구현을 해놓지 않으면 매번 논리주소와 물리주소사이의 짝짓기 하다가 껨오바될것은 자명한 이치죠. 이젠 슬슬 본격적인 기초 메모리 관리 테크닉들을 논할때가 다가오고 있군요. 그 신호탄으로써 먼저 스와핑(swapping)을 살펴보도록 하죠. 여기서의 스와핑은 필수적으로 백킹스토어(다름아닌 하드드라이브)를 필요로하며, 프로세스단위로 일어나는 현상입니다. 즉, 요구되는 프로세스를 메모리에 로딩하기 위하여 먼저 필요없는 프로세스 한개를 스왑아웃(또는 roll out)시킨뒤 해당 프로세스를 스왑인(또는 roll in)시키는 것입니다. 여기서 한번 스왑아웃되었던 프로세스가 다시 스왑인 될때에는 원래 자신이 메모리에 있었던 위치에 오게 될지 아닐지는 전적으로 바인딩 기법에 따라서 좌우되요. MMU의 리로케이션레지스터를 이용한 엑세큐션타임 바인딩의 경우 런타임중 메모리의 물리적인 주소값이 그때그때 결정되기에 다시 스왑인되었을때의 위치가 전에 있던 위치와 달라도 되겠죠. 별거 아닌거 같지만 중요한 차이점입니다. 일부 성격급한 분들, 지금 저것이 바로 버쳐메모리여~!!! 하고 좋아하시겄지만, 아따, 거 뒤게 급하시네 그랴,,,아직 버쳐 메모리 다루려면 다다음 문서에서나 가능할듯 허니 먼저 여기서 천천히 기초 쌓는 작업부터 합시다요. 물론 버쳐메모리가 스와핑을 이용하기는 하지만, 버쳐메모리의 핵심은 그것이 아닙니다. 이제껏 다룬 내용 및 위의 상황을 어느정도 이해했다는 전제하에 프로세스가 실행되는 과정을 제대로 다시 기술해 보기로 하죠. 프로세스 스케줄링의 주연급인 레디큐부터 재등장시켜보면, 레디큐는 메모리내에 할당됨으로써 준비를 마친 프로세스들 뿐만 아니라 백킹스토어내에서 자신의 이미지를 만들고 준비를 마친 프로세스들 또한 포함하고 있었습니다. 씨피유 스케줄러가 어떤 프로세스를 실행하기로 결정을 내리면 제일먼저 디스패처를 부르게 되고 디스페쳐는 다음 실행될 프로세스가 메모리에 있는지 부터 확인하게 되는 것이죠. 만일 프로세스가 없다면 이때 사용가능한 메모리가 있는지를 확인하고, 없다면 바로 스와핑이 해결사의 필살기로 등장하게 되는것입니다. 스와핑이 일어날때의 컨텍스트 스위칭에 걸리는 시간은 꽤 크겠죠? 더구나 스와핑시 걸리는 시간의 대부분은 데이터 전송 시간이니 만큼, 얼마만큼의 메모리가 스와핑되는가와 걸리는 시간은 비례하게 됩니다. 고로 라운드라빈알고리즘을 이용할때에는 스와핑시 부여되는 타임퀀텀 또한 적절하게 증가시켜줘야겠지요. 이래저래 복잡해지고 있는 오에스이군요. 스와핑시 정말 주의해야 할 점이 하나가 있지요. 간단하게 생각해서 I/O를 요구해놓고 기다리는 프로세스가 스왑아웃당했다고 칩시다. I/O의 결과는 그럼 어디로? 이것을 해결하는 방법은 두가지가 있는데, 첫째는 일단 I/O를 기다리고 있는 프로세스는 절대로 스와핑 대상에서 제외시키는것과, 두번째는 I/O를 하긴 하되, 반드시 시스템 버퍼(system buffer)를 이용해서 중간 저장매체를 언제나 경유하게 만드는 것입니다. 둘다 나름대로의 장단점이 있으니 잘 생각해 보시기 바래요. 휴우,,,이거 두장정도로 끝내려 했는데 산넘어 산같은 주제로군요. 실제 교과서에서도 메모리에 관한것만 두챕터를 할당하고 있거든요. 일단 여기까지 메모리 관리 테크닉을 이해하기 위한 기본이었다고 생각하시면 될듯싶습니다. 다음장에서는 메모리를 어떻게 조각내서 사용하면 좋을까를 고민하다가 탄생한 페이징 기법과 세그멘테이션 기법에 대한 내용을 다루어보려 합니다. 이번 내용을 제대로 이해하셨다면 그다지 어렵지 않은 내용일겁니다 :) -duffer 경준 (http://vorlon.cwru.edu/~kxm73)
|