Fix typos in Memory Management chapter (#95)

* Fix typos in Memory Management chapter

* Fix typos in Heap Allocation Chapter

* Add name to acknowledgements

Author: hannahfluch

04_Memory_Management/01_Overview.md

@@ -43,11 +43,11 @@ Usually this is the lowest level of allocation, and only the kernel should acces
 
 ## Paging
 
-Although Paging and VMM are strongly tied, let's split this topic into two parts: with paging we refer to the hardware paging mechanism, that usually involeves tables, and registers and address translation, while the VMM it refers to the higher level (usually architecture independant).
+Although Paging and VMM are strongly tied, let's split this topic into two parts: with paging we refer to the hardware paging mechanism, that usually involves tables, and registers and address translation, while the VMM it refers to the higher level (usually architecture independent).
 
 While writing the support for paging, independently there are few future choices we need to think about now:
 
-* Are we going to have a single or mulitple address spaces (i.e. every task will have its own address space)? If yes in this case we need to keep in mind that when mapping addresses we need to make sure they are done on the right Virtual Memory Space. So usually a good idea is to add an extra parameter to the mapping/unmapping functions that contains the pointer to the root page table (for _x86\_64 architecture is the PML4 table).
+* Are we going to have a single or multiple address spaces (i.e. every task will have its own address space)? If yes in this case we need to keep in mind that when mapping addresses we need to make sure they are done on the right Virtual Memory Space. So usually a good idea is to add an extra parameter to the mapping/unmapping functions that contains the pointer to the root page table (for _x86\_64 architecture is the PML4 table).
 * Are we going to support User and Supervisor mode? In this case we need to make sure that the correct flag is set in the table entries.
 
 ## VMM - Virtual Memory Manager
@@ -71,7 +71,7 @@ Similarly to paging there are some things we need to consider depending on our f
 
 ## Heap Allocator
 
-There is a disntiction to be made here, between the kernel heap and the program heap. Many characteristic are similar between each other, although different algorithm can be used.
+There is a distinction to be made here, between the kernel heap and the program heap. Many characteristic are similar between each other, although different algorithm can be used.
 Usually there is just one kernel heap, while every program will have its own userspace heap.
 
 - At least one per process/running program, and one for the kernel.
@@ -99,7 +99,7 @@ char *a = alloc(5);
 What happens under the hood?
 
 1. The alloc request the heap for pointer to an area of 5 bytes.
-2. The heap allocator searches for a region big enough for 5 bytes, if available in the current heap. If so, no need to dig down further, just return what was found. However if the current heap doesn't contain an area of 5 bytes that can be returned, it will need to expand. So it asks for more space from the VMM. Remember: the *addresses returned by the heap are all virtual*.
+2. The heap allocator searches for a region big enough for 5 bytes, if available in the current heap. If so, no need to dig down further, just return what was found. However, if the current heap doesn't contain an area of 5 bytes that can be returned, it will need to expand. So it asks for more space from the VMM. Remember: the *addresses returned by the heap are all virtual*.
 3. The VMM will allocate a region of virtual memory big enough for the new heap expansion. It then asks the physical memory manager for a new physical page to map there.
 4. Lastly a new physical page from the PMM will be mapped to the VMM (using paging for example). Now the VMM will provide the heap with the extra space it needed, and the heap can return an address using this new space.
 

04_Memory_Management/02_Physical_Memory.md

@@ -34,23 +34,23 @@ So marking a memory location as free or used is just matter of setting clearing
 
 ### Returning An Address
 
-But how do we mark a page as taken or free? We need to translate row/column in an address, or the address in row/column. Let's assume that we asked fro a free page and we found the first available bit at row 0 and column 3, how we translate it to address, well for that we need few extra info: 
+But how do we mark a page as taken or free? We need to translate row/column in an address, or the address in row/column. Let's assume that we asked for a free page and we found the first available bit at row 0 and column 3, how we translate it to an address, well for that we need a few extra infos: 
 
-* The page size (we should know what is the size of the page we are using), Let's call it `PAGE_SIZE`
-* How many bits are in a row (it's up to us to decide it, in this example we are using an unsigned char, but most probably in real life it is going to be a `uint32_t` for 32bit OS or `uint64_t` for 64bit os) let's call it `BITS_PER_ROW`
+* The page size (we should know what the size of the page we are using is), Let's call it `PAGE_SIZE`
+* How many bits are in a row (it's up to us to decide it, in this example we are using an unsigned char, but most probably in real life it is going to be a `uint32_t` for 32bit OS or `uint64_t` for 64bit OS) let's call it `BITS_PER_ROW`
 
 To get the address we just need to do: 
 
 * `bit_number = (row * BITS_PER_ROW) + column`
 * `address = bit_number * PAGE_SIZE`
 
-Let's pause for a second, and have a look at `bit_number`, what it represent? Maybe it is not straightforward what it is, but consider that the memory is just a linear space of consecutive addresses (just like a long tape of bits grouped in bytes), so when we declare an array we just reserve *NxSizeof(chosendatatype)* contiguous addresses of this space, so the reality is that our array is just something like: 
+Let's pause for a second, and have a look at `bit_number`, what it does it represent? Maybe it is not straightforward what it is, but consider that the memory is just a linear space of consecutive addresses (just like a long tape of bits grouped in bytes), so when we declare an array we just reserve *NxSizeof(chosendatatype)* contiguous addresses of this space, so the reality is that our array is just something like: 
 
  | bit_number | 0 | 1 | 2 | ... | *8* | ... | 31 | *32* | ... | 63 |
  |------------|---|---|---|-----|-----|-----|----|------|-----|----|
  | \*bitmap   | 1 | 1 | 1 | ... | *0* | ... |  0 |  *0* | ... |  0 |
 
-It just represent the offset in bit from `&bitmap` (the starting address of the bitmap). 
+It just represents the offset in bit from `&bitmap` (the starting address of the bitmap). 
 
 In our example with *row=0 column=3* (and page size of 4k) we get:
 
@@ -66,7 +66,7 @@ But what about the opposite way? Given an address compute the bitmap location? S
 
 $$bitmap_{location}=\frac{address}{4096}$$
 
-In this way we know the "page" index into an hypoteteical array of Pages. But we need row and columns, how do we compute them? That depends on the variable size used for the bitmap, let's stick to 8 bits, in this case:
+In this way we know the "page" index into a hypothetical array of Pages. But we need row and columns, how do we compute them? That depends on the variable size used for the bitmap, let's stick to 8 bits, in this case:
 
 * The row is given by `bitmap_location / 8`
 * The column is given by: `bitmap_location % 8`