Paging States

Depends on	Paging

The figure below is an attempt to show a possible state diagram for a virtual memory page. Each potential page will have its own state.

As a key to transitions, actions prompted by the user’s application are in green.

Start with the page unallocated.

One possible time-line of a page might be as follows:

• The user requests some virtual address space and the (potential for a) page is allocated. Any access to an unallocated address will cause a segmentation fault. At this time, physical memory may not have been assigned. The page table entry indicates the page is invalid but the operating system software knows the addresses are usable.
• The application reads from the page.
  • as it is (supposedly) invalid there is a page fault
  • the exception handler allocates some physical memory
  • the page is filled from disk (reading a page with no contents is also possible, but silly)
  • the page is marked as ‘read only’
  • the application continues

Alternatively…

• The application writes to the page.
  • as it is (supposedly) invalid there is a page fault
  • the exception handler
    • checks if writing is allowed: allocates some physical memory if so or the protection causes a segmentation fault
  • the page may be filled from disk (a ‘blank’ page for new data is not silly, though)
  • the page is noted to be writeable: this implicitly indicates it has been written to and is thus ‘dirty’
  • the application continues

Writing to a read-only page has a similar effect to writing to a new page.

• Sometimes, the system may be short of (physical) memory and evict this page for a while.
  • a ‘clean’ (read-only) page can be simply overwritten: there is a backup copy already
  • a ‘dirty’ (read-write) page must be saved
  • the page is then marked ‘invalid’ as attempts to use it must fault again
• An access to a swapped-out page will cause a fault and bring it back from the disk (after checking permissions such as “is a write allowed”).
  The page table will be updated because the physical RAM used for the data is freshly allocated – the virtual address is, of course, the same as ever.
• When the process completes, or otherwise frees the memory explicitly, the operating system notes that these virtual addresses are no longer legal.

Notes

• This is just one possible model: other scenarios are possible. This does, however, cover most of the principles involved in a typical implementation.
• Privilege is not included, above; a user read (for example) would also cause a segmentation fault if the page was private to the operating system.

---

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Virtual Memory

Memory • Memory Fault • Memory Management • Memory Management Unit (MMU) • Memory Mapping • Memory Mapping Example • Memory Mapping Extra • Memory Pages • Memory Protection • Memory Segmentation • Page Eviction • Paging • Paging States • Shared Memory • Translation Look-aside Buffer (TLB) • Virtual Memory

Articles on Memory

About this resource • Arrays • Cache • Caching • Direct Memory Access (DMA) • Dirty Bit • Dynamic Memory Allocation • Memory • Memory Barrier • Memory Fault • Memory Leak • Memory Management • Memory Management Unit (MMU) • Memory Mapped Files • Memory Mapping • Memory Mapping Example • Memory Mapping Extra • Memory Pages • Memory Protection • Memory Segmentation • Memory Sizes • Monitoring page behaviour • Page Eviction • Paging • Paging States • Pointer Arithmetic • Pointers • Relocatable Code • Resources • Shared Memory • Structures • Translation Look-aside Buffer (TLB) • Virtual Memory • Write Buffer