Advanced Virtual Memory

What is it?

The virtual memory features beyond basic mapping: copy-on-write fork, large pages, memory hints, section objects shared between views, per-process memory limits, DMA buffers, compressed memory, NUMA placement and Address Windowing Extensions. A few pieces exist in forms the roadmap does not yet claim (1 GiB kernel pages, single-process section objects, Job Objects without memory limits), and the rest is not built.

How does it work?

Large pages. The kernel direct map uses 2 MiB pages, which vmm_split_huge_page() breaks into 4 KiB pages when a caller needs finer permissions. On CPUs that report 1 GiB page support (CPU_FEATURE_PAGE1GB), vmm_promote_to_1g() runs during Phase 0 (boot_hw.c) and folds eligible identity-map ranges into 1 GiB pages, and vmm_map_huge_1g() maps an aligned 1 GiB range directly (vmm.h). There is no user-facing large-page allocation.

fork. SYS_FORK (5) creates a child process with task_fork(), but pages are not shared copy-on-write: the fork-then-exec path gives the child private frames through vmm_remap_user_page(), and the frame allocator has no reference counts.

Section objects. ob_section.h defines SECTION_OBJECT with up to SECTION_MAX_VIEWS (16) views and the SEC_IMAGE, SEC_RESERVE, SEC_COMMIT and SEC_NOCACHE flags. nt_section.c registers create, open, map, unmap, extend and query services. Backing memory comes from pmm_alloc_contiguous() up front, so a SEC_RESERVE section still commits frames, and mapping or unmapping a view in another process returns STATUS_ACCESS_DENIED.

Job Objects. ob_job.h supports only the active-process limit and kill-on-close (JOB_SUPPORTED_LIMIT_FLAGS); any other limit flag, including process and job memory limits, returns STATUS_NOT_SUPPORTED because there is no per-process commit accounting to enforce them against.

AWE. The three physical-page services are registered to NtAWE_stub, which returns STATUS_NOT_IMPLEMENTED (nt_memory.c).

What are its interfaces?

Interface	Purpose
`vmm_split_huge_page()`, `vmm_map_huge_1g()`, `vmm_promote_to_1g()`	Kernel large-page management (`vmm.h`)
`SYS_FORK` (5)	Process fork without copy-on-write
`ObCreateSectionEx()`, `ObMapViewOfSection()`, `ObUnmapViewOfSection()`, `ObExtendSectionObject()`	Section objects and views (`ob_section.h`)
`NtCreateSection` and related services	NT section surface (`nt_section.c`)
`NtCreateJobObject` and related services	Job Objects without memory limits (`ob_job.h`)

How do I use it?

Kernel code that needs finer permissions inside the direct map splits the covering page first with vmm_split_huge_page(). Large-page splitting, 1 GiB mapping alignment and section round trips are covered by the memory, CPU and Object Manager suites, including test_vmm.c:

bash scripts/test.sh SUITE=mm
bash scripts/test.sh SUITE=x86
bash scripts/test.sh SUITE=ob

What is not implemented yet?

Copy-on-write fork with frame reference counts (COW fork()).
User 2 MiB pages and MAP_HUGE (Huge Pages (2 MiB)).
1 GiB pages for device MMIO. The kernel promotion exists; its use for PCI BARs and the boot report line do not (1 GiB Pages (Kernel MMIO)).
madvise and MEM_RESET hints (madvise / MEM_RESET Hints).
Cross-process section views and sparse SEC_RESERVE sections (Section Object Multi-View Mappings).
Job Object memory limits (Per-Process Memory Limits (Job Objects)).
DMA buffer pool, compressed memory, NUMA-aware allocation and transparent huge pages (Zero-Copy DMA Buffer Pool, Compressed Memory, NUMA-Aware PMM, Transparent Huge Pages Collapser).
Address Windowing Extensions (AWE).

How does it compare with Windows 11 and Linux?

Windows 11 has large pages, section objects with views in any process, Job Object memory limits, memory compression, NUMA and AWE, but no fork. Linux has copy-on-write fork, MAP_HUGETLB, madvise, zram, dma_alloc_coherent, NUMA and khugepaged. Impossible OS has kernel large pages and single-process sections, with every roadmap row still planned; the roadmap takes both families, offering copy-on-write fork alongside Win32 sections and Job Object limits.