[Memory] Memory Consideration in OS

이상하게 우리나라 OS강의나 외국 OS강의의 서두에는 항상 위 시스템이 나온다. 위 시스템은 IBM에서 개발된 프레임워크인 System 360이다. 이게 큰 의미를 갖는 이유는 물론 최초로 application을 구동할 수 있는, 컴퓨터의 개념을 정립한 시스템인 것이다. 그런데 OS관점에서 보면 또다른 의미를 부여할 수 있는데 아마 Multiprogramming이 가능한 OS가 탑재되었다는 것이다. 이전에 나왔던 system은 Batch System이라고 해서 사용자가 프로그램의 시작전에만 설정하고 나머지는 시스템에서 알아서 돌아가는 시스템이었다. 즉, 프로그램의 구동중에는 사용자가 개입할 여지가 없다는 것이다. 요즘과 같이 작업관리자가 여러 프로그램을 메모리에 올리고 따로따로 구동하는 방식이 아니라 그냥 비슷한 일들을 묶어두고 구동하는 형식이었다. 물론 이렇게 하면 System Resource를 비슷한 일을 처리하는데 집중할 수 있기 때문에 효율적으로 사용될 수 있겠지만, 여러일을 동시에 처리하고자 하는 사람에게는 불편한 구조였다. 

 그래서 이 System 360이 도입되면서 Memory상에 사용자가 원하는 Job들을 올리고 구동하는 방식을 채택하게 되었다. 당연히 어떤 일들을 먼저 처리해야 할지에 대한 Policy가 정립되어야 하고, 보통 이런 Policy를 Job Scheduling이라고 표현한다. 그런데 Memory에 Job이 올라가면서 문제가 발생하게 된다. Memory의 영역에 한번 프로그램들이 올라가기 시작하면 해당 프로그램의 데이터를 읽어오기 위해서는 해당 프로그램이 Load되어있는 Address를 받아야한다. 우리가 이 주소를 찾을 때는 보통 포인터를 사용해서 해당 주소에 들어있는 값을 가져오게 된다. 그런데 만약 프로그램이 저장되어 있는 주소는 고정되어있는데 반해, 사용자가 포인터를 잘 못 사용해서 다른 주소를 참고하게 되면 어떻게 될까? 분명 OS는 그점을 인지하고 사용자에게 오류를 알려줘야 한다. 이런 오류를 segmentation fault라고 한다. 그림으로 표현하면 다음과 같이 된다. 

그래서 이렇게 오류를 알려주는 Mechanism 자체를 Memory Protection이라고 한다.  Multiprogramming으로 전환되면서 모든 job들이 Memory에 올라가기 때문에 고려되어야 할 요소가 된 것이다. 

그러면 다음으로 고려되어 할 것이 자기가 수행하고자 하는 Job이 Memory의 어떤 영역에 할당되서 처리될 건지에 대한 Relocation이 고려되어야 한다. 당연한 이야기이겠지만 Memory상에 올라간 job들은 그 위치가 어디에 놓여져있던간에 정상적으로 동작해야 하고, 자기만의 영역을 가지고 있어야 하며, 그 영역은 그 job만의 고유 영역이 되어야 한다. 이때 다른 프로그램이 그 영역을 침범하던가, 그 영역을 사용하게 될때는 이에 대한 경고를 해줘야 한다. 그러면 이걸 효과적으로 알수 있는 방법이 뭘까? 그러면 각 job에 대한 시작점과 job이 Memory내에서 할당받은 size만 알고 있으면 되지 않을까? 그 시작점과 size를 표현하는게 Base & Bound Register다. CPU내에 현재 instruction의 bound를 나타내는 Base Pointer가 있는 것처럼 각 프로그램도 자기가 어떤 위치에서 시작하는지에 대한 정보를 가지고 있게 된다. 그럼 위의 예시에서 job1이 job2의 영역을 침범하지 않기 위한 조건은 바로 size가 700을 넘지 않아야 된다는 것이다. 즉 job1이 처리할 수 있는 데이터는 base register는 300이며 bound register는 700이라는 정보를 갖게 된다. 당연히 이 값을 넘게 되면 다른 영역에 또 할당을 해야 될 것이다. 

사실 이부분은 OS가 신경쓰는 부분이 아니라 하드웨어적으로 구현되어 있는 Memory Management Unit에서 해주는 부분이다. 그래서 위에서 예시로 언급한 Mechanism자체가 MMU의 주요 역할이 되겠다. 

그러면 이 부분을 하드웨어로 해주니까 소프트웨어로 구현된 OS에서는 이걸 신경쓸 필요가 없지 않을까 하는 생각을 해본다.  우리가 최소한의 Error를 피하기 위해서는 앞에서 언급한 Memory Protection과 Relocation측면에서 Base register와 bound register를 MMU에게 알려줘야 한다. 따라서 OS도 MMU의 존재를 인지하고 있어야 한다는 것이다. 

 이밖에도 Memory에 저장된 Data를 여러 job들이 이용할 때 그 Data에 대한 Synchronization이 고려되어야 한다. 예를 들어서 한쪽에서 Memory위에 있는 데이터를 수정하고 나서 다른 쪽에서 그 데이터를 사용하고 할때 수정된 것을 모르고 사용하게 되면 당연히 문제가 발생할 것이다. 그래서 그 데이터에 대해서는 수정되었는지의 여부가 다른 job들에게도 알려져야 한다. 이걸 고려하는 것이 Concurrent Programming 이 된다.

 지금까지 OS내에서 발생할 수 있는 문제를 봤다. 그런데 거진 대부분의 문제가 MultiProgramming을 구현하면서 job들이 memory상에 올라가면서 발생하는 문제들이다. 이 때문에 고려해야될 요소가

- memory Protection

- Memory Relocation

- Concurrent Programming

등이 있다는 걸로 요약할 수 있겠다.

reference : 

- 서울대학교 열린 강의 - 운영체제의 기초 : http://snuon.snu.ac.kr/_HTML/course_view.php?id=36&page=1