Virtual Memory: Goals
Trnasparency
user가 physical memory를 신경 안쓰고 코드를 짤 수 있도록, process가 memory가 공유되고 있다는 사실을 모르도록
Efficiency
-
Fragmentation을 줄여야함 (space)
-
hardware support를 받아야함 (time)
애초에 memory를 접근할 때 OS를 거치지 않는 이유가 시간 효율때문이다. 따라서 hardware에서 적절히 권한 체크를 잘해줘야 함,, 이를 위해 OS에서는 hardware로 정보를 넘겨줘야 한다!
Protection (제일 중요!!!)
- process나 OS를 다른 process로부터 지켜야함
- Isolation : Process가 죽을 때 다른 프로세스 건드리지 말고 혼자 죽어야함
갑자기 생각난 건데, 크롬 창도 여러개 띄울 때 공유자원을 가진 상태로 죽으면 안되니까 멀티 프로세스로 만든다 ! (멀티 쓰레드 말고) - 협력하는 process들은 메모리의 일부를 share할 수도 있다.
즉, protect하는 동시에 share도 가능하게 해야함
Virtual Address Space
Process의 관점에서 memory를 볼 때는, OS가 illusion을 만들어주기 때문에 private한 address space가 있다고 생각함
read-only나 read/write segment는 fixed size이고, heap과 stack의 경우 Dynamic하게 바뀐다. (runtime에 할당 받음)
Virtual Memory
- 각각의 process는 own virtual address space를 가진다.
- Address translation은 run time에 실행된다.
(virtual address -> physical address로의 맵핑) - Lazy allocation 가능
프로그램은 얘네의 모든 address space를 physical memory에 올려 놓지는 않는다. 필요한 부분만 동적으로 할당 가넝Static Relocation
Software-based relocation
요론식으로 OS가 (!!) memory에 load하기 전에 address를 바꿔줌
얘의 문제는 허용되지 않은 memory space를 건드릴 수도 있고(runtime 모니터링이 불가능함), 할당된 후에 옮기기 어려움
대신 hardware support가 필요 없어서 좋음
Dynamic Relocation
Hardware-based relocation
Fixed Partitions
Physical memory를 fixed partition으로 나눔
이런 경우는 context switching할 때 OS가 base register값을 PCB에 저장해놓음
그리고 Hardware가 변환을 하는 것임
이러면 context switching할 때 빠름 (register 하나만 바꿔주면 되니까)
하지만 internal fragmentation의 문제,,
따라서 여러개의 size로 partition을 만들 수도 있음
이런 식으로 접근 가능한 limit이 정해져 있어서 protextion fault 감지가 가능함
그런데 이렇게 되면 internal은 해결해도 external fragmentation 문제가 생기고, sharing이 불가능해짐
Segmentation
그래서 address space를 logical segment로 나누자 !!
code / data / heap / stack 이런식으로 나눔!
이제 프로세스마다 !! 이런 segment registers나 table이 있는 것
이런 식이면 stack - heap 이렇게 배치돼서 그 사이 공간을 임의로 크게 잡아줄 필요가 없음 heap segment를 그냥 맨위에 올리고 그 위의 빈공간 놔두고, stack은 아래에 넣고
그런데 문제가 생길 수 있는 건 만약 서로 다른 process에서 동일한 physical address에 접근할 때 각 process에서 해당 address의 segment영역이 다르고, pointer 값을 직접 넘겨주게 된다면 앞의 segment number가 달라서 문제가 생길 수 있긴 함
valid bit도 있어서 protect도 쉬운데 share하기도 쉽다.
code/data share가 주
하지만 각각의 segment로 인해 external fragmentation 발생 가능하고, Large segment table 또한 메모리에 들고 있어야 하니까 cache를 사용해서 속도 향상시켜줌
