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?
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: