Reference Set

The Short Story

When a Windows process allocates memory, that amount of Virtual Address Space is committed (a bookkeeping event), but Virtualized RAM is not assigned until the memory is accessed (read/written). For example, when a module is loaded, its code is not loaded into RAM and attached to the process (paged-in) until it is actually executed.

Thus, Virtual Address Space is allocated, but Virtualized RAM is demand-paged-in as it is accessed.

Here we focus mostly on tracing RAM usage as its corresponding code/data is paged-in on demand.

Quick Start

• Download and unzip MSO-Scripts.
  Close as many applications as possible.
  
• MSO-Scripts\TraceMemory Start <option>
  Exercise the code.
• MSO-Scripts\TraceMemory Stop <option>
• MSO-Scripts\TraceMemory View <option> [-FastSym]
  option:
  -Lean: RAM page-in events (ReferenceSet), no stackwalk
  -Lite: VirtualAlloc (Private Commit Charge), with stackwalk
  -Stats: Capture memory stats per process every ½ second
  -Snap: Capture a Resident Set memory snapshot
    None: All of the above, with stackwalk.
  

Note that Stop and View commands can be combined using -WPA:

• MSO-Scripts\TraceMemory Stop <option> -WPA [-FastSym]

List all options:

• MSO-Scripts\TraceMemory -?

The Long Story

Measuring RAM Usage

The two most common ways to measure RAM usage in Windows are Working Set and Reference Set:

Working Set is the RAM currently in use by each process, according to the Windows Memory Manager.
This value can rise and fall depending on application behavior and system-wide demands for physical RAM (memory pressure).
This value is measure by several tools: Task Manager, Process Explorer, VMMap, ETW/WPA Memory Stats

Reference Set is an accounting of RAM usage by each process over a time interval.
It is different from Working Set in several ways:

• It is not affected by working set "trimming" (paging out, usually due to memory pressure).
• It may attribute Windows OS memory usage to the process which initiated its use.
• It is unique to the Windows Performance Analyzer (WPA) as it analyzes ETW memory traces.
• Since it is based on memory paging events, it can be attributed to running code via stackwalk.

See also:

• Working Set
  
• Reference Set
  

Windows Memory Sharing

When code modules or data files are loaded by multiple processes, the RAM containing the code/data may be shared across the processes.

Reference Set (WPA only)

• System View: RAM shared across processes is attributed only to the first process to access it within the trace.
  
• Process View: Whether RAM is shared across processes is not considered. It counts toward all processes which access/page-in the RAM.
  (Use WPA's View Editor to choose whether the System View or Process View columns are enabled.)

Working Set (WS)

• Private WS: RAM associated with Committed Virtual Memory which CANNOT be shared across processes, such as Heap, Stack, etc.
  
• Shareable WS: RAM associated with Committed Virtual Memory which CAN be shared across processes, such as code, read-only data, File-backed Sections, etc.
  
• Shared WS: The subset of Shareable WS which IS actually shared across two or more processes.
  
• Shared Commit (ie. Shareable Commit Charge): The subset of the Committed Virtual Memory which consists of Pagefile-backed Sections. (This memory can be shared across processes. Any system-wide summation should avoid double-counting.)
  
• Total Commit (ie. Total Commit Charge): The subset of the Committed Virtual Memory which is backed by the system pagefile, such as Heap, Stack, as well as Pagefile-backed Sections. (Conceptually this is the same as Private WS + Shareable Commit Charge.)
  

See also: Windows Memory Cheat Sheet

Screenshots

RAM Usage - File
When modules and data files are loaded into memory, they immediately occupy the address space of the entire module/file. But RAM is consumed (paged-in) on demand, as the module/file is accessed (read, written, or executed). This is Reference Set.

Table of RAM usage associated with file-backed Virtual Memory such as code modules and memory-mapped data files.

Legend

• Page Category
  
  • Image: Modules
    
  • MapFile: Memory Mapped Files   (Pagefile-mapped Section, see above: RAM Usage - Allocated)
    
  • MetaFile: Folders and Bookkeeping Structures on Disk
    
• Description: File Name and Path
  
• Impacting Stack / Size: "Impact" implies RAM consumption.* TODO: TRUE?

* See: Windows Memory Sharing: System View and Process View

RAM Usage - Allocated
When memory is dynamically allocated, it immediately occupies the requested address space. But RAM is consumed (paged-in) on demand, as the data is read and written. This is Reference Set.

Table of RAM usage associated with dynamically allocated Virtual Memory via HeapAlloc, VirtualAlloc, etc.

Legend

• Page Category:
  
  • Win32Heap: Virtual memory used by the Windows Heap Manager.
    
  • VirtualAlloc: Lowest level Windows virtual memory allocator (generic allocations not associated with other subsystems).
    
  • PagedPool: Windows Kernel memory (often associated with Registry operations).
    
  • NonPagedPool: Windows Kernel memory which cannot page out (often associated with drivers).
    
  • PFMappedSection: Memory mapped against the system pagefile (with a shareable handle).
    
  • User/Kernel Stack: Committed virtual memory allocated by threads for their stacks.
    
  • CopyOnWrite/COW: Writable memory which is initially shared across processes until modified, at which point separate copies are created in RAM.
    
  • PageTable: Windows bookkeeping to manage virtual memory.
    
• Impacting Size/Stack: "Impacting" implies RAM consumption.* TODO: TRUE?
  
• Allocation Stack: The execution stack where the virtual memory allocation occurred. (This column is off by default.)
  
• Size _Sum : Sum total size of committed virtual memory allocations (virtual memory churn, not necessarily consuming RAM).* TRUE?
  
• Size _{Peak Outstanding} : Maximum total size of unfreed, committed virtual memory allocations (not necessarily consuming RAM), with the time stamp of the peak.* TRUE?

* See: Windows Memory Sharing: System View and Process View
  The System/Process Views will differ only in these shareable memory sections (above):
  ◦ PFMappedSection (pagefile-backed, memory-mapped section)
  ◦ Prefetcher (for optimizing process launch)
  ◦ Driver

Note

Wherever you see lots of "n/a" in the Impacting Stack column, and Impacting Size ≈ 0, that is likely virtual address space which was allocated but (mostly) not paged-in. Therefore it has little impact, consuming little RAM. To see its allocation/origin, open the View Editor (Ctrl+E) and enable the Allocation Stack column.

Commit Charge
The Commit Charge is the subset of the Committed Virtual Address Space which is charged to (backed by) the system page file. Commit Charge, being a class of address space, is only indirectly related to RAM Usage / Reference Set.

Legend

• Commit Type:
  • Win32 Heap - The address space of the Windows Heap.
  • Virtual Alloc - The address space otherwise allocated through VirtualAlloc.
  • PFMappedSection - The address space memory-mapped against the system page file (with a shareable handle).
  • Copy on Write - The address space which is shareable across processes until modified, when a separate copy is created.
• Count/Size _Sum : The sum total count and size of commit charge memory allocations (the churn).
• Count/Size _{Peak Outstanding} : The aggregate count and size of unfreed commit charge allocations at their peak, with the time stamp.
• Commit Stack: The execution stack where the commit charge allocations occurred.
• Impacting Size: The difference in size between the end and the start of the trace, or of the zoomed view.

Memory Stats - ½ sec
Every ½ second statistics on the various categories of memory usage are captured for all processes running on the system.

Legend

• Process (pseudo-processes):
  • PagedPoolWs: Paged Pool kernel memory allocator - Working Set
  • SystemPteWS: System Page Table Entries (virtual memory bookkeeping) - Working Set
  • SystemCacheWS: System Cache Manager - Working Set
• Time: Timestamp of each measurement relative to the start of the trace.
• Virtual Size: The per-process, virtual address space committed or reserved (only relevant for 32-bit processes).
• Working Set: The amount of RAM claimed by each process (some of it may be shared across processes).
• Private Working Set: The amount of RAM claimed by each process that cannot be shared across processes.
• Commit (i.e. Commit Charge): The subset of committed virtual address space charged to (backed by) the system pagefile.

Resident Set
The Resident Set is a snapshot of how physical RAM is currently employed on the system.
It is the set of memory pages that currently reside in physical memory.

Legend

• MMList
  • Active:
  • Modified:
  • Standby:
• Page Category
  • Image
  • CopyOnWriteImage
  • PagedPool
  • NonPagedPool
  • MapFile
  • COWMapFile
  • PFMappedSection
  • COWPFMappedSection
  • Win32Heap
  • VirtualAlloc_PreTrace
  • VirtualAlloc
  • UserStack
  • KernelStack
  • Prefetcher
  • MetaFile
• Description:
• Page Priority:
• Pinned:

Important

For the Resident Set view to work correctly, you must launch WPA with -Snap: TraceMemory View -Snap ...
If launching WPA directly, you must omit the switch: -cliprundown
More info, run: WPA -? "Event Tracing for Windows"

See also:

• RAMMap
• Resident Set Definition

What is "Commit"?   Commit Charge vs. Committed Address Space

There is potential for confusion surrounding these two terms, as both may be referred to as "Commit."

• Committed Address Space: Every 4 KB page of the address space of a process will be in one of three states:
  • Committed: Allocated & accessible. When accessed, the corresponding data will be demand-paged-in to occupy the address space.
  • Reserved: Not free to allocate and cannot be accessed (until explicitly committed).
  • Free: Cannot be accessed until allocated.
• Commit Charge: the subset of the Committed Address Space which is charged to (backed by) the system page file.

Important

This totality of the Commit Charge across all processes cannot grow to be greater than the available System Commit Charge, which is the sum of the size of the System Page File(s) plus the size of usable Physical RAM. Else the Windows Virtual Memory Allocator will throw Out-Of-Memory errors.

Consider the worst case scenario for the Windows Memory Manager:
Every committed memory region across all processes gets fully paged-in and modified (if writeable).
Then it all gets paged-out.
Q: Where does it all page-out to?
A: The part of it which would page-out to the system page file is the Commit Charge: the subset of the Committed Address Space which is charged to (backed by) the System Page File.

If the Commit Charge were to grow without bounds then eventually there could be nowhere for it to page-out to, resulting in a blue-screen virtual memory failure. For this reason the system-wide bookkeeping happens at allocation-time to prevent over-committing.

Examples:

• The Windows Heap constitutes part of the Commit Charge, since its virtual memory is charged to (backed by) the system pagefile.
• The runtime code in a module is not part of the Commit Charge, since its virtual memory is backed by the corresponding .exe/.dll file.
• A memory-mapped data file is not part of the Commit Charge, since its virtual memory is backed by the corresponding data file on disk.
• A pagefile-backed section constitutes part of the Commit Charge, since it is backed by the system pagefile.

See also: Windows Memory Cheat Sheet