주소 바인딩

본문 전제가 이상합니다. MMU는 virtual to physical memory mapping입니다. 링커나 로더는 virtual address만 보거나 physical address를 봅니다. 전자의 경우, virtual address는 응용 프로그램에서 보면 추상된 physical address고 굳이 원래 physical address가 뭐였는지 알 필요 없이 대부분의 경우에 사용 가능해야 합니다. 따라서 언제 symbol resolution이 일어나는지와는 관계가 커보이지 않습니다.

컴파일 타임 바인딩만으로 충분하지 않은 이유와 쉐어드 라이브러리가 필요한 이유가 상당히 겹칠 겁니다. share library를 안 쓴다면, code는 언제나 특정 virtual address에 배치하고, global 영역, heap, stack은 어디서부터 어디까지 배치하고.. 이런 식으로 정하는 게 불가능하진 않을 겁니다.

shared library가 들어가게 되면, 이제 그 프로세스의 address space에 커널 + 실행파일 (및 그 컨텍스트) 뿐만 아니라 임의의 개수의 shared library까지 포함하게 됩니다. shared library마다 각각 virtual address를 고정시켜 주는 건 이제는 매우 어렵겠죠. 그래서 shared library는 process마다 virtual address space 상의 다른 위치를 차지하게 됩니다. 이런 경우는 기본적으로 혹은 나이브하게는 load time에 address를 정해줄 수 있습니다.

세 가지 중에 소위 execution time에 address binding을 하는 경우는.. 여러 가지가 있겠습니다만, shared library를 어떻게 efficient하게 loading하느냐의 관련된 문제들이 많습니다. 나이브한 접근 방식은 share library를 loading time에 load 해놓고 address를 계산해 주는 거겠죠.

하지만 실제로는 그렇게 안 하는데, lazy loading이라고 부릅니다. loading time을 짧게 하고 처음 호출이 되면, 그때 로딩을 해놓는 거죠.
https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter3-7.html

그밖에 웹 서버가 아주 오래 전에는 cgi 요청 들어오면 exec, fork, redirect 등을 해서 서비스를 해줬을 텐데, process를 하나 만드는 건 효과적이지 않죠. 그걸 런타임 라이브러리로 만든다고 가정해 봅시다. 원래는 1000가지의 별도의 프로그램이 있어서 exec, fork, redirection을 해가며 썼다고 하고요. 이젠 대충 1000개의 .so가 필요합니다. 이걸 언제 load할 거냐가 문제겠죠. 웹 서버의 load time에 하면 1000개를 전부 로드해야 됩니다. 하지만 실제로는, 이를테면, 1000개 중에 4 ~ 5개만 엄청나게 자주 요청되고 나머지는 드물게 되거나 할 거고요. 그러면 1000개를 로드 타임에 다 로드하는 건 효율적이지 않습니다. 더 나은 방식은 아마 처음 요청을 받으면 그 라이브러리만 로드해서 캐슁을 하고, 안 쓰인지 오래 되면 버리는 거겠죠. 그러러면 런타임에 load해서 address binding이 가능해야 합니다.

그리고.. 그냥 한 가지 더 생각할 만한 건, JAVA VM 같이, 평소에는 interpreter인데 runtime에 모니터 하다가 hot spot을 발견하면, just-in-time 컴파일을 하고 이제는 interpreting 대신 그 컴파일된 코드를 사용하는 경우일 겁니다. 그때 binary translation이 뒤늦게 런타임에 된 코드는 로딩이 될 때 주소도 고정되기 어렵겠죠. 이런 feature를 시스템이 허용한다면 도대체 어떤 프로그램이 언제 몇 개의 그런 류의 코드를 생성할지 예측할 수 없으니까요.