Week 12 Reflection: Paged Memory System
Published: 2021-12-10 03:13:31

Hello everyone, welcome back to the SPO600(Software Portability and Optimization) week 12 blog. In this blog, we will find something fun with the paged memory system.

##Instruction##
Most modern systems use page memory. It means the physical memory of the system is divided into pages and these pages can then be arranged via memory table or memory map into a memory configuration that is viewed by a process. It allows us to present a different view of memory to different processes and thus isolate some areas of memory that are visible from one process but invisible for another process and it also allows us to share memory between processes.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tw2aezviw696xipolmwv.png)

This diagram here shows the relationship between physical memory and logical memory or virtual memory. In this diagram the current process is a game process. So we noticed that on the left hand side we have the view of memory that is visible to that process. So the game process appears to have 4 pages of virtual memory corresponding to three pages of physical memory and they don't have to be contiguous in physical memory like where they are located in virtual memory. The size of each page in the x86_64 system is commonly 4k or 1M, in the AArch64 system it is usually 4k or 64k.

##How much memory is process using##
To define how much memory a process uses is a  quite difficult question because we need a standard counter to calculate the size that a process page is presenting and has been allocated at that moment. So we have two different standard sizes VSS(Virtual Set Size) and RSS(Resident Set Size). The VSS all of the pages that are present in the virtual memory or logical memory for that process. It actually counts all of the memory no matter if the page has been allocated or not, it is the worst case to calculate the size. There's also the RSS, the resident set size only counts the pages that are physically present in memory, it excludes the pages which haven't yet been loaded from disk or haven't been swapped out to disk. It would give us a more accurate picture of the actual physical usage of memory by a particular process.

##What it looks like##
To see what it looks like on an actual operating system, we need to use this command: 
```
top 
```
For my personal laptop, I got this result below:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f8ha0a0100kd94hn9fwp.png)
As we can see, I got 11946.7 mebibytes in total, 5615.7 mebibytes for free, 740.6 mebibytes in use, and 5588.7 mebibytes for buff and catch.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fxlhnfse2y968jpqwu3q.png)
Below this, we could see individual processes. I used the top command which has VIRT(Virtual Set Size), RES(Resident Set Size), and SHR(Share Memory Size).

##Conclusion##
This week we learned almost the last topic of this course. To be honest, this course is the hardest course for me so far because the programming level of this course is lower than the other computer science classes that I took before like C++, Java, JavaScript, etc. However, it is fun to look at how and where a program actually works and what the compiler and systems could do to run the program that we created. In this course, I worked with 6502 assembly language, assembly language in x86_64 and AArch64 systems, and algorithms to speed up a program. I think I have got a picture of how to run a program at a lower level and I hope I could explore more about it.