12장 컴포넌트
컴포넌트 = 시스템의 구성 요소로 배포할 수 있는 가장 작은 배포 단위
잘 설계된 컴포넌트 - 독립적으로 배포 가능 즉, 독립적으로 개발 가능한 능력 O
컴포넌트의 간략한 역사
개발 초창기
→ 메모리에서 프로그램 위치와 레이아웃을 프로그래머가 직접 제어
- 시작부에 오리진 구문(프로그램이 로드될 주소 선언) (ex. *200)
- 위치 결정 이후 재배치 X
- 라이브러리는 바이너리가 아니라 소스코드 형태로 유지되어 프로그래머가 어플리케이션 코드에 직접 포함시켜 컴파일
⇒ 컴파일 시간 ↑
∴ 함수 라이브러리 소스코드를 애플리케이션 코드로부터 분리
- 함수 라이브러리 개별적으로 컴파일
- 컴파일된 바이너리를 메모리의 특정 위치에 로드
- 함수 라이브러리에 대한 심벌 테이블 생성 후 이를 이용해 애플리케이션 코드 컴파일
- 애플리케이션 실행 시, i) 바이너리 라이브러리 함수 로드 ii) 애플리케이션 로드
⇒ but, 애플리케이션 크기가 커짐에 따라 추가 공간 할당해야하는 문제 발생
재배치성
해결책
→ 지능적인 로더를 사용하여 메모리에 재배치가 가능한 바이너리를 생성하도록 컴파일러 수정
-
로더는 재배치 코드가 자리할 위치 정보 전달 받음
-
재배치 코드에는 로드한 데이터에서 어느 부분을 수정해야 정해진 주소에 로드할 수 있는지를 알려주는 플래그(대게 바이너리에서 참조하는 메모리의 시작 주소) 삽입됨.
-
로더는 여러 개의 바이너리를 입력 받은 후 차례로 메모리로 로드하면서 재배치 (∴필요한 함수만을 로드 가능)
-
재배치 가능한 바이너리 안의 함수 이름을 메타데이터 형태로 생성
- 프로그램이 라이브러리 함수 호출 시 컴파일러는 라이브러리 함수 이름을 외부 참조(external reference)로 생성
- 라이브러리 함수를 정의하는 프로그램이라면 컴파일러는 해당 이름을 외부 정의(external definition)으로 생성 → 외부 정의를 로드할 위치가 정해지기만하면 외부 참조를 외부 정의에 링크 시킬 수 있게 됨 ⇒ 링킹 로더 의 탄생
링커
프로그램 크기가 ↑수록 링킹 로드가 속도 ↓
∴ 로드와 링크 두 단계로 분리
- 링커
- 프로그래머가 링크 과정 담당.
- 링크가 완료된 재배치 코드를 만듦. (속도 ↑)
but, 각 모듈을 컴파일 하는 시간은 줄었지만 전체 모듈을 컴파일하는 시간이 걸렸고 이후 링커에서 더 많은 시간 소요.
로드 시간은 여전히 ↓ but 컴파일-링크 시간은 ↑
- 무어의 법칙 → 디스크 크기 ↓, 속도 ↑, 메모리 가격 ↓, 디스크에 저장된 데이터 모두를 RAM에 캐싱 가능, clock rate 100MHz까지 증가
- 컴퓨터와 장치가 빨라서 다시 로드와 링크를 동시에 할 수 있게 됨. → 컴포넌트 플러그인 아키텍처(component plugin architecture)의 탄생
결론
소프트웨어 컴포넌트의 예 → 런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일
정리
개발 초창기에는 라이브러리는 소스코드 형태였고 메모리에서 프로그램 위치가 제어됐었는데 컴파일 속도가 오래 걸려 함수 라이브러리를 애플리케이션 코드와 분리하여 개별적으로 컴파일 하고 바이너리 형태로 변환하였음.
추가 공간 할당에 대한 문제를 해결하기 위해 링킹 로더가 고안 되었지만 이도 속도 때문에 링커와 로더로 분리되었다.
