메모리 관리 (1)

전에 친구와 컴파일러와 인터프리터의 차이에 대해 이야기 했었던 적이 있다. 그 때에는 정말 공부를 시작한지 얼마 안됬었고 인터프리터가 무엇인지도 몰라 친구가 알려주는 얘기만 들었던 것 같다.

 

그런데 이번에 다시한번 컴파일러와 인터프리터의 관한 이야기가 나왔고 이번에는 그 두가지의 장단점/ 왜 둘을 분류해서 사용할까와 같은 여러 의문점을 가질 수 있었다. 

 

먼저 내가 생각했던 첫번째 의문점은 인터프리터에는 링커가 들어가지 않는다는 것 이다.

 

링커는 자주 사용하는 함수를 라이브러리에 보관하여 헤더에만 지정하면 쉽게 쓸 수 있는데 왜 인터프리터에서는 쓰지 않을까라는 생각을 했었는데

 

다시 생각해보니 인터프리터는 한줄한줄 바로 실행되는데 헤더에 지정을 한다는 것 자체가 잘못된 생각이였다는 것을 알 수 있었다. 

 

또한 컴파일러는 실행 전 변수를 한번 정해놓으면 밑으로는 쭉 그 변수를 사용할 수 있지만 인터프리터는 변수를 그때그때 지정하는 번거로움이 있다면 결국 시간이 비슷하거나 더 오래 걸리지 않을까 라는 생각을 했었는데 

 

이것에 대한 내용은 내가 아직 인터프리터 언어를 사용해보지 않아서 잘 모르겠다.

---

1. 메모리 관리의 개요

 

1-1 메모리 관리의 복잡성

 

메모리 주소 레지스터 : CPU가 메모리에 있는 내용을 가져오거나 작업 결과를 메모리에 저장하기 위해 사용

 

- 시분할 시스템을 사용하여 메모리에 여러 프로세스를 올려놓고 실행하기 때문에 복잡

- 운영체제 또한 프로그램이므로 메모리에 올라와야 실행 가능 (사용자 메모리와 별개)

- 메모리 관리 시스템 (MMS)가 메모리를 관리

 

1-2 메모리 관리의 이중성

 

 

- 메모리의 빈 공간을 어떻게 처리할지

- 자신보다 큰 용량의 프로세스를 실행할 때 어떤 프로세스를 밀어낼지 

- 프로세스 입장에서 작업의 편리함과 관리자 입장에서 관리의 편리함의 충돌

 

1-3 소스코드의 번역과 실행

 

1) 컴파일러와 인터프리터의 차이

• 컴파일러 : 소스코드를 컴퓨터가 이해할 수 있는 기계어로 번역한 후 한꺼번에 실행
• 인터프리터 : 소스코드를 한 행씩 번역하여 실행

2) 컴파일러의 목적

• 오류발견 : 선언하지 않은 변수를 사용한다거나 하는 오류를 실행전 발견한다. → *심벌 테이블 사용
• 코드 최적화 : 많은 양의 코드를 입력하다 보면 중복되는 코드가 있을 수 있다. 또는 굳이 필요없는 변수를 선언하거나 하는 등의 낭비되는 요소를 제거하고 코드를 최적화한다.

3) 인터프리터의 목적 

• 한줄한줄 실행하기 때문에 컴파일러보다 빠르다는 장점이 있다.
• 작고 간단한 프로그램에 사용하기 적합

4) 컴파일러와 인터프리터의 차이

컴파일러	인터프리터
사용할 변수 먼저 선언	필요할 때 변수 선언
주로 대형 프로그램에 사용	작고 간단한 프로그램에 사용
오류찾기와 코드 최적화등 작업이 편리	실행이 편리

1-4 메모리 관리자의 역할

 

- 가져오기 : 사용자가 요청하면 프로세스와 데이터를 메모리로 가져오는 작업 

ㄴ 사용자의 요청이 없더라도 앞으로 필요할 것 같은 데이터를 미리 가져오기도 함 (캐시)

 

- 배치 : 가져온 프로세스와 데이터를 메모리의 어떤 부분에 올려놓을지 결정하는 작업

 

- 재배치 : 꽉 차 있는 메모리에 새로운 프로세스를 가져오기 위해 오래된 프로세스를 내보내는 작업

 

2. 메모리 주소

 

2-1. 32bit CPU와 64bit CPU의 차이

 

: CPU의 bit는 한 번에 다룰 수 있는 데이터의 최대 크기이다. 

물리 주소 공간 : 하드웨어적으로 바라본 주소 공간. 절대적 주소의 형태

논리 주소 공간 : 사용자의 입장에서 바라본 주소 공간. 상대적 주소의 형태

 

2-2. 절대주소와 상대주소

 

• 운영체제 영역 : 운영체제 영역은 시스템을 관리해야하기 때문에 사용자가 함부로 침범해선 안된다. 따라서 운영체제만이 독립적으로 사용하는 공간이다.
• 사용자 영역 : 사용자가 실질적으로 사용하는 메모리 공간이다. 

운영체제가 업데이트되며 메모리를 더 사용하게 된다면 위 7-9 사진의 360부터였던 사용자 영역이 더 줄어들게 된다. 이를 방지하기 위해서 상위 메모리부터 사용자 영역을 할당하는 방법도 있다. (주소를 999부터 시작)

- 주소의 변경이 복잡하기 때문에 잘 사용하지 않음

 

절대주소 : 위 7-9 사진에서 사용자 영역의 400번에 프로세스를 할당한다고 했을 때 운영체제 영역을 포함한 실질적 주소 (400)

상대주소 : 운영체제영역을 포함하지 않고 360번을 0으로 시작하여 사용자 중심의 메모리 주소 (40)

 

3. 단일 프로그래밍 환경에서의 메모리할당

 

3-1 메모리 오버레이

 

메모리 오버레이 : 프로그램의 크기가 실제 메모리보다 클 때 프로그램을 메모리에 가져오는 대신 적당한 크기로 잘라서 가져오는 기법

 

• 프로그램 전체를 메모리에 올려놓고 실행하는 것보다 속도가 느리지만 큰 프로그램을 실행할 수 있음 (가상메모리의 기초)
• 프로그램 일부만 메모리에 올라와도 실행이 가능하다

3-2 스왑

 

스왑영역 : 메모리가 모자라서 쫒겨난 프로세스를 모아두는 저장공간

스왑인 : 스왑에서 메모리를 가져오는 것

스왑아웃 : 스왑영역으로 데이터를 내보내는 것

 

- 사용자는 스왑메모리와 실제메모리의 크기를 합쳐서 전체 메모리라고 인식할 수 있다. 

 

ex) 윈도우에서의 최대 절전 모드를 할 때 컴퓨터의 전원이 꺼지는데 다시 켰을 때 기존의 메모리가 복구된다. 이를 스왑 영역에 보관한 것이다.

 

용어정리

 

심벌 테이블 : 변수 선언부에 명시한 각 변수의 이름과 종류를 모아놓은 테이블

경계 레지스터 : 메모리의 운영체제 영역과 사용자 영역의 기준

물리 주소 공간 : 하드웨어적으로 바라본 주소 공간. 절대적 주소의 형태

논리 주소 공간 : 사용자의 입장에서 바라본 주소 공간. 상대적 주소의 형태

스왑영역 : 메모리가 모자라서 쫒겨난 프로세스를 모아두는 저장공간

스왑인 : 스왑에서 메모리를 가져오는 것

스왑아웃 : 스왑영역으로 데이터를 내보내는 것