가장 기본적인 이점은 프로세스가 가상 메모리를 물리적으로 할당하는 방법에 대해 걱정할 필요가 없도록 하는 추상화 계층을 제공하는 것이며 이는 운영 체제에서 처리된다는 것을 알고 있습니다. 그러나 그 외에 어떤 장점/단점을 기대할 수 있습니까?
답변1
각 프로세스는 컴퓨팅 초기에 그랬던 것처럼 한 번에 한 컴퓨터에서 실행되는 단일 프로그램 모델을 따르는 고유한 주소 공간을 갖습니다. 최신 시분할 운영 체제에서 프로세스는 여전히 전용 CPU와 메모리를 사용하여 실행되는 것처럼 세상을 봅니다. (이것은 약간 단순화된 것입니다. 프로세스는 물론 IPC 메커니즘을 통해 다른 프로세스에 대해 배울 수 있습니다.)
이제 대안인 컴퓨터에서 실행되는 모든 프로세스가 공유하는 주소 공간을 살펴보겠습니다. 프로그램이 시작될 때 실행 중인 프로세스에서 메모리 주소를 이미 사용하고 있으므로 프로그램이 메모리에 로드될 때 메모리 세그먼트를 재배치해야 합니다. 프로그램의 메모리 레이아웃은 매번 다를 수 있으며 프로그램은 시작하기 전에 "즉시" 다시 연결되어야 합니다.
공유 메모리 공간은 서로 다른 프로세스에 속한 페이지를 메모리 공간 전체에 분산시켜 달성할 수 있습니다. 이를 위해서는 각 메모리 영역(페이지 또는 세그먼트)이 해당 영역을 소유한 프로세스에 대한 정보와 연결되는 정교한 보호 체계를 하드웨어에 구현해야 합니다. 또한 이 솔루션은 메모리가 단편화되고 프로그램 로드에 실패할 수 있다는 단점도 있습니다. 연속된 메모리 주소가 있는 큰 영역이 필요할 수 있고 충분히 큰 영역을 사용하지 못할 수 있기 때문입니다.
또 다른 접근 방식은 각 프로세스에 대해 연속적인 메모리 공간을 예약하는 것입니다. 이렇게 하면 보호 체계가 더 단순해지지만(하한 및 상한만) 주소 공간이 낭비되고 조각화가 발생합니다.
이와 다소 관련이 있는 것은 관련되지 않은 많은 프로세스에서 공유하는 코드와 데이터를 포함하는 공유 라이브러리입니다. 공유 라이브러리의 페이지는 수정되지 않은 상태로(즉, 프로세스별 절대 주소 패치 없이) 메모리에 로드되는 것이 이상적입니다. 그렇지 않으면 프로세스 간에 물리적 메모리 프레임을 공유할 수 없습니다. 반면, 공유 라이브러리는 서로 다른 프로세스의 서로 다른 가상 주소에 로드되어야 하는 경우가 많습니다. 그렇지 않으면 다루기가 어려워집니다. 최신 공유 라이브러리는 위치 독립적 코드를 사용하고 간접 참조를 통해 데이터에 액세스하므로 대부분 수정되지 않은 상태로 두고 다른 가상 주소를 사용하여 계속 실행할 수 있습니다. 1세대 Linux "a.out" 공유 라이브러리는 실제로 더 단순했으며 주소 공간의 고정된 위치에 로드되었습니다. 이를 위해서는 알려진 각 공유 라이브러리에 대한 가상 주소의 중앙 레지스트리를 유지해야 하며 향후 성장을 위해 일부 추가 공간을 예약해야 합니다.