What exactly is a memory page fault?

Question

From the docs:

Note: Core Data avoids the term unfaulting because it is confusing. There's no “unfaulting” a virtual memory page fault. Page faults are triggered, caused, fired, or encountered. Of course, you can release memory back to the kernel in a variety of ways (using the functions vm_deallocate, munmap, or sbrk). Core Data describes this as “turning an object into a fault”.

Is a Fault in Core Data essentially a memory page fault? I have only a slight idea about what a memory page is. I believe it's a kind of "piece of code in memory" which is needed to execute procedures and stuff like that, and as the app is runing, pieces of code are sucked into memory as "pages" and thrown away as they're not needed anymore. Probably 99% wrong ;)

Anyone?

Answer 1

While your program is running not all of it stored on the RAM.
There are paging mechanisms as part of the OS that stores only the most used memory page in the RAM for faster access.
When you program trying to access a memory location that is not currently loaded to RAM a page fault occur and the page is brought from the disk.
Since the RAM available is limited only the most important memory pages stored in RAM.

This mechanism is subject to OS implementation.
For more comprehensive exploration of operating systems theory I would recommend the book Modern Operating Systems by A.S.Tenenbaum.

Answer 2

A memory page is the basic unit of data for your application from the operating system's perspective. All of your code and data is arranged in groups of pages. When your program references a legal memory location within your application - either by attempting to read or write data or load an instruction, the address is translated into a location in one of these pages. A page fault occurs when the page holding the address is not actually present in physical memory. At that point the operating system needs to load the page from disk into memory so that your program can continue.

Answer 3

I have only a slight idea about what a memory page is. I believe it's a kind of "piece of code in memory" which is needed to execute procedures and stuff like that, and as the app is runing, pieces of code are sucked into memory as "pages" and thrown away as they're not needed anymore.

Stuff (i.e. code and data) exist in memory.

Each thing which exists in memory has an address (a memory address).

The memory address space (e.g. 4GB on a 32-bit machine) is divided into 'pages', where each page is a contiguous chunk of memory (e.g. 4KB per page).

The address space is mapped (by the CPU and the O/S) into RAM (or possibly mapped to I/O ports, but that's a different story).

There may be less RAM installed (e.g. 1 GB) than there is address space (e.g. 4 GB), therefore some stuff (e.g. the least-recently-used stuff) may be swapped out (by the O/S) from RAM onto a page file on disk. Whole, integral pages (e.g. 4KB chunks) are what's swapped (not individual bytes).

When the application tries to access an address which isn't currently mapped to RAM, then that's a so-called page fault. To handle a page fault, the O/S might:

• Free some RAM, by swapping something (e.g. least-recently-used) from RAM to disk
• Map that newly-freed now-available RAM to the address which the application is trying to access
• Swap into RAM, from disk, whatever is supposed to be at that address (which at some time in the past had been swapped out from that address to disk)
• Resume the application where it left off: the application tries again to access that memory address, only this time without another page fault.