메모리 관리의 개요

메모리 관리의 복잡성

• 메모리는 1B 단위로 나뉨
• 1B단위로 나뉜 각 영역은 메모리 주소를 구분하는데, 0번지 부터 시작
• CPU는 메모리에 데이터를 쓰거나 / 가져오기 위해 MAR ( Memory Address Register )를 사용
• MAR에 필요한 메모리 주소를 넣으면, 데이터를 메모리에서 가져오거나, 메모리에 옮길 수 있음
• 일괄 처리 시스템에서는 메모리에 하나의 작업만 처리 했기 때문에, 메모리 관리가 어렵지 않았으나, 시분할 시스템에서는 운영체제를 포함한 모든 응용프로그램이 메모리에 올라와 실행되기 때문에 관리가 복잡 ( 도마에 올라간 재료가 하나 / 여러개 임을 상상하면 쉬움 )
• 메모리에는 운영체제도 올라 와 있음을 기억 !
• 메모리 관리의 이중성
  • 프로세스는 메모리리를 독차지 하려 하고, 메모리 관리자 입장에선 되도록 관리를 효율적으로 하고자 함
  • 프로세스 입장에서 작업의 편리함과 관리자 입장에서 관리의 편리함이 충돌을 일으키는 일
• 프로그램을 메모리에서 실행하는 이유
  • SSD를 사용하면 안되나 ? → 가격이 비쌈
  • CPU속도와 동일한 속도로 작업을 처리하는 캐시메모리도 작지만 속도가 빠름 ( 가격이 비쌈 )

컴파일러 / 인터프리터

• 프로그래머가 고급 언어 ( 인간이 이해할 수 있는 개발 언어 ) 작성 된 코드를, 컴퓨터에서 실행 가능한 코드로 변경 하는 작업이 필요함

• 언어 번역 프로그램

  • 고급 언어 ( 사용자가 이해하기 쉽게 프로그래밍 할 수 있는 언어 ( java / c ... )로 작성 한 소스코드를 컴퓨터가 실행 할 수 있는 기계어로 번역 해주는 프로그램
  • 언어 번역 프로그램의 일종으로 컴파일러 / 인터프리터가 존재
  • 컴파일러

    • 소스코드를 컴퓨터가 실행 할 수 있는 기계어로 번역 한 후 한꺼번에 실행

    • 윈도우에서 실행 가능한 확장자의 이름은 exe인 경우가 잦은데, 이는 컴파일러가 번역 한 기계어 코드의 확장자가 exe 라는뜻

    • 요리 예제

      • 요리 레시피를 보고, 전체 레시피를 훑어보며 오류나 불필요한 내용이 있는지 살펴봄
      • 예를들어 양배추가 소스 만드는데 필요하지만 준비 재료에 적혀있지 않다면 컴파일에러를 띄워 요리사에게 에러를 노출시킴
      • 또 양파를 써는 과정에서 양파를 1개씩 써는 작업이 3번이 적혀 있다면 양파 3개를 한번에 썰도록 레시피를 최적화 하는 작업을 거침
      • 또 필요하지 않은 재료가 준비물에 적혀 있다면 경고 메세지를 요리사에게 띄워 줄 수 있음

    • 목적

      • 실행하기 전에 코드를 점검하여 오류를 수정하고 최적화 → 빠른 실행파일을 만드는것이 목적 !
      • 오류 발견
        • 소스코드에서 오류를 발견하여 실행 시 문제가 없도록 하는 것
        • 심벌 테이블을 사용 !
          • 심벌 테이블 : 변수 선언부에 명시한 각 변수의 이름과 종류를 모아놓은 테이블
          • 선언하지 않은 변수를 사용하지는 않았는지, 변수에 다른 종류의 데이터를 저장하지는 않았는지 확인 할 수 있음
      • 코드 최적화
        • 양파 1개를 썰어 볶는 작업이 두번 서술되어 있다면 2개를 썰어 볶는 작업으로 합칠 수 있음
        • 또 사용되지 않는 불필요한 재료들도 삭제 할 수 있음

    • 컴파일 과정

      1. 소스코드 작성 및 컴파일
         • 프로그래머가 작성 한 코드를 0 / 1 로 이루어진 목적 코드 ( object code )로 변환한다.
      2. 목적 코드와 라이브러리 연결
         • 라이브러리에서 가져와 사용한 함수의 기계어 코드를 1번의 과정에서 생성한 목적코드에 삽입하는 과정
         • C언어에서 printf()함수를 <stdio.h> 라이브러에서 가져와 목적 코드에 삽입하는 단계
      3. 동적 라이브러리를 포함하여 최종 실행
         • 동적 라이브러리 ?
           • 라이브러리에서 가져 온 코드를 활용( 위 2번의 작업 까지 )하여 실행 파일을 생성 한 이후엔, 라이브러리에서 가져 온 코드의 변경에 대응 할 수 없는 상태이다. ( 이미 라이브러리안의 코드를 가져와 실행파일에 삽입 되어 있기 떄문 )
           • 따라서 라이브러리의 업데이트나, 코드 변경 사항에 반응 할 수 없다는 단점을 보완하고자, 라이브러리에 있는 코드의 실제 구현체는 비워두고, 실행 시 동적으로 라이브러리속에서 해당 코드를 가져오는 작업을 진행 할 수 있다.
           • 이때 실행할 때 삽입되는 함수를 가진 라이브러리를 동적 라이브러리 라고 칭한다.
           • 동적 라이브러리를 활용하면, 라이브러리 속 함수가 변경되도라도 새로 컴파일 할 필요 없이 라이브러리만 변경하여 사용하여 주면 된다.
           • DLL ( Dynamic Link Loader )로 칭하기도 함

      • 여러 프로그래머 ( A, B, C )가 작업 한 것을 합치려고 할 때는, A, B, C가 작업 한 결과물을 컴파일 한 목적 코드를 합쳐 컴파일 하는 것이 수월함 ( 분할 컴파일이라 칭함 )

        • 목적 코드가 만들어 졌다는 것 자체가, 소스코드의 오류 검증과 최적화가 이루어 진 상태라는 것을 의미하기 때문

      • 변수와 메모리 할당

        char str = 'a';
        int vol = 1234;
        float pi = 3.14;
        

        • 기계어는 메모리 주소를 사용
        • char str = 'a';는 기계어에서는 메모리 주소 0번지에 a를 넣으라는 명령으로 번역
        • 컴파일러는 0번지에 a를 넣고, 이곳을 문자형이 들어가는 공간으로 기억
        • char / int / float는 보관 하려는 자료의 형태를 나타낼 뿐 아니라, 사용하려는 메모리의 크기를 나타내기도 하고 이를 기반으로 심벌 테이블을 생성 함

        심벌 테이블

        • 위 테이블에서 범위는, 각 변수를 사용 할 수 있는 영역 ( scope )를 나타냄
        • 컴파일러는 변수를 사용 할 때 마다, 범위를 벗어나지는 않았는지 체크함
        • 변수 종류마다 크기가 정해져 있기 때문에, 변수의 시작 주소만 명시하면 그 크기는 자동으로 정해짐
        • 위를 종합해보자면, 변수는 메모리 주소와 같은 말이다
        • 메모리 주소는 프로그래머가 기억하고 읽기 힘드므로, 메모리 주소에 프로그래머가 읽기 편한 이름을 지어 변수로 사용 하는것
  • 인터프리터
    • 소스코드를 한 행씩 번역하여 실행
    • 요리 예제
      • 요리 레시피를 보고, 요리 레시피에 적힌 대로 위에서 아래로 한줄 씩 읽어가며 요리를 완성하는 과정

  메모리 관리자의 역할

  • 메모리 관리 유닛 이라는 하드웨어가 메모리를 관리한다.
  • 가져오기 ( fetch ) / 배치 ( placement ) / 재배치 ( replacement ) 작업을 진행한다.
  • 가져오기
    • 프로세스와 데이터를 메모리로 가져오는 작업
    • 프로세스와 데이터를 모두 가져오는 경우가 많고, 특정 상황에서는 일부만 가져와 사용하기도 함
    • 용량이 큰 동영상 플레이 같은 경우, 플레이어는 전부 가져와 실행하지만 동영상은 필요할 때 마다 수시로 가져와 실행하도록 함
    • 앞으로 필요 할 것으로 예상되는 것을 미리 가져오기도 함
    • 가져오기 정책
      • 프로세스가 필요로 하는 데이터를 언제 메모리로 가져 올 지 결정하는 정책
      • 요청 할 때 가져오는게 일반적이지만, 미리 가져오는 경우도 존재 ( prefetch )
  • 배치
    • 가져온 프로세스와 데이터를 메모리의 어떤 부분에 올려 놓을 지 결정하는 작업
    • 배치 작업 전에 메모리를 어떤 크기로 자를 것인지가 매우 중요
    • 실행되는 프로세스의 크기에 맞게 자르느냐, 그렇지 않느냐 ... 에 따라 배치 작업이 크게 달라짐
    • 나누어진 메모리의 구역에 따라 프로세스와 데이터를 어떤 위치에 놓을 지 결정하는 것이 배치 작업
    • 배치 정책
  • 재배치

  메모리 주소

  32Bit CPU와 64Bit CPU의 차이

  • CPU Bit → 한 번에 다룰 수 있는 데이터의 최대 크기
  • 32Bit CPU는 한번에 다룰 수 있는 데이터의 최대 크기가 32Bit
  • CPU 내부 부품은 모두 이 비트를 기준으로 제작
  • 32Bit CPU의 경우 레지스터 / 산술연산자 / 버스의 크기 / 대역폭 등이 모두 32BIt
  • 따라서, 메모리 주소 레지스터의 크기도 32Bit
  • 메모리 주소 레지스터의 크기가 32Bit이므로, CPU는 접근 할 수 있는 메모리 주소의 범위가 0 ~ $2^{32}-1$ 가 되고 총 크기는 $2^{32}$Bit, 약 4GB가 된다.
  • 따라서 32Bit CPU의 경우 사용 할 수 있는 메모리의 최대 크기는 4GB이다.
  • 64Bit의 경우엔 메모리를 $2^{64}$Bit, 약 16,777,216 TB 까지 사용 가능 하다.

  절대 주소와 상대 주소 차이

  • 메모리 영역 구분
  • 절대 주소 / 상대 주소
  • 상대 주소 값에 재배치 레지스터 값을 더해 절대 주소값을 구함