Stage D · Experimental evidence · October 2026

Inspect memory.
Don't change it.

A read-only debugger can alter the process it observes. We benchmarked two Linux remote-memory readers to quantify performance, copy-on-write effects and access semantics.

ARM64 / Neoverse-N1Linux 6.17.0-1018-oracle4 KiB pages10 repeats per configuration
0

COW pages split by proc

100%

Tracked COW pages split by vmread

3.9×

Faster cold read with proc at 256 KiB, contiguous

+29%

Faster warm read with vmread at 256 KiB, contiguous

01 / Throughput

Two readers. Different costs.

Switch between memory layouts and cold or warm reads. Bars show median MiB/s; white ticks mark the 25th–75th percentile interval across ten repeats.

/proc/<pid>/memprocess_vm_readv()Higher is better ↑

Exact medians and interquartile intervals
BlockMethodP25MedianP75
Cold read includes any COW work induced by the initial inspection. Warm throughput uses five further passes. Timing excludes fork, pagemap, smaps and file open/close overhead.
02 / Copy-on-write

Read-only doesn't mean side-effect-free.

Fraction of tracked private pages physically unshared after reading a forked child's memory.

vmread: unsharedproc: unshared
Every observed vmread case on this kernel caused 100% tracked-PFN divergence before an application write; every proc case preserved sharing. Do not assume identical behavior on other kernels.
03 / Access semantics

What counts as readable?

In an explicit 4 KiB probe crossing PROT_NONE regions and unmapped holes, the readers returned different byte counts. These are not equal-workload performance tests.

/proc/<pid>/mem read additional PROT_NONE pages on this tested kernel; process_vm_readv() did not. Both failed on holes. Access to another process still requires appropriate inspection permissions; this is not a privilege-escalation claim.
04 / Methodology

Measured, not assumed.

Direct syscall-level microbenchmarks, separate from RuntimeXRay's end-to-end tracing and scanning paths.

01 · Forked fixture

Each case uses a fresh fork. A 32 MiB contiguous arena or 25.62/25.50 MiB of readable mappings spread across 410/102 VMAs. Reads use 4, 64 or 256 KiB blocks.

02 · Ten repetitions

Every reader × block × layout was measured ten times. Charts show median and interpolated P25–P75. Contiguous runs alternate reader order; VMA runs have fixed order.

03 · Five warm passes

Five subsequent reads follow each cold pass. Physical-page sharing is counted outside the timed loop. Opening and closing /proc/pid/mem is also excluded.

Environment

ARM Neoverse-N1 · Oracle VM with 1 vCPU · Linux 6.17.0-1018-oracle on AArch64 · Ubuntu 24.04-based kernel · 4096-byte pages · measured 22 Oct 2026 UTC · 180 primary data rows and a separate single-run probe.

Reproduction

cc -std=c11 -O2 -Wall -Wextra -Werror tests/benchmarks/benchmark_remote_memory_cow.c -o /tmp/rxr-cow sudo /tmp/rxr-cow --mb 32 --warm 5 --method both cc -std=c11 -O2 -Wall -Wextra -Werror tests/benchmarks/benchmark_remote_memory_vma.c -o /tmp/rxr-vma sudo /tmp/rxr-vma --mb 32 --warm 5 --segment-pages 16 sudo /tmp/rxr-vma --mb 32 --warm 5 --segment-pages 64 sudo /tmp/rxr-vma --mb 32 --warm 5 --segment-pages 16 --probe

Limitations: one kernel and single-vCPU VM; host scheduling may vary. The compared fixtures keep work equivalent in maps-aware mode. Probe intentionally does not. Results describe read-loop throughput, not total scanning cost. The proc backend requires additional open/close calls outside the timing region.

Contiguous fixture ↗ VMA fixture ↗ Stage D notes ↗