

An Introduction to Virtual Memory - RageD
http://deathbytape.com/post/110371790629/intro-virtual-memory

======
Stratoscope
This is a nice write-up. A couple of minor corrections:

First, in several places it talks what a physical RAM "chip" looks like in
terms of its memory layout. It would be better to simply think of an address
space instead of a physical chip. Even without virtual memory, you don't know
- and don't care - how the hardware addresses an actual chip. It may not even
be a chip! The same principles would apply with old-fashioned magnetic core
memory or any other kind of memory.

Also, this is completely wrong:

> Swapping at the granularity of 4KB chunks mitigates the issues caused by
> fragmentation (since they are small).

If you're comparing segmentation with paging, then paging doesn't just
"mitigate" fragmentation. Fragmentation simply doesn't exist when you always
allocate the same size memory blocks. It's not because the 4KB pages are
"small" \- segmented memory often used much smaller allocations than that. You
could have any size page and it would be the same thing: there's no such thing
as fragmentation in this situation.

Consider the difference between a heap allocator that manages blocks of any
requested size vs. one where all blocks are the same size. In the latter case,
your allocator can simply consist of a list of free blocks. To allocate a
block, you take one from the list. To free a block, you add it to the list.
It's that simple, and there is no opportunity for fragmentation to happen
here. And this is completely independent of the block size, as long as all
blocks are the _same_ size.

Of course you could sub-allocate memory _within_ or overlapping your pages,
using some other kind of memory allocator like malloc(), and those memory
allocations would suffer fragmentation just as segmented memory does. But
again that fragmentation is due to the fact that you're allocating different
sized blocks, and it's a separate question from whether the paging mechanism
itself can become fragmented.

~~~
RageD
Great point, thanks for pointing this out! I have updated the write up to
address this.

------
mandeepj
Great write-up

More detailed resources -

[http://www.red-gate.com/community/books/under-the-hood-
dotne...](http://www.red-gate.com/community/books/under-the-hood-dotnet-
memory-management) \- Contrary to title, it is not dotnet specific

[http://support.microsoft.com/kb/2160852?wa=wsignin1.0](http://support.microsoft.com/kb/2160852?wa=wsignin1.0)

[http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtual...](http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm)

~~~
tomjakubowski
I'll add a link to the 80386 manual's section on page translation, which
describes in more detail the multi-level page table structures that the
article mentions.

[http://www.logix.cz/michal/doc/i386/chp05-02.htm](http://www.logix.cz/michal/doc/i386/chp05-02.htm)

Multi-level page tables were definitely a necessity in the early days of
32-bit computing, when a 4MB linear page table (required to map all of the
32-bit address space) was quite a lot of memory to ask for!

------
encoderer
I remember the first time I realized, with the help of _Computer Systems - A
Programmers Perspective_ that virtual memory was not some extra storage locker
of fake RAM on your hard drive, but instead an abstraction as important as the
process or the file. I unlocked a new level that day.

~~~
khnd
+1 @ Computer Systems - A Programmers Perspective. This book is hotfire.

------
js2
For further details, see
[http://people.freebsd.org/~lstewart/articles/cpumemory.pdf](http://people.freebsd.org/~lstewart/articles/cpumemory.pdf)

