Windows 11 25H2 の Working Set 挙動を実測してみた。Windows のメモリ管理を本気で観測したら、結局 C++ が基準言語になった話
※ 本記事では Working Set 昇格の内部評価ロジックそのものを断定するものではない。
あくまで観測可能な挙動（WS / PageFault の推移）から、
「アクセスの継続性（滞在時間）が影響しているように見える」
という傾向を示したものである。
本記事の検証は筆者の環境・条件での観測結果であり、
製品の不具合や仕様を断定するものではありません。
同様の結果が再現されるかは環境差があります。
はじめに
Windows のメモリ管理、とくに Working Set（WS） や Page Fault（PF） の挙動は
「理論では知っているけど、実際にどう増えるのか？」を正確に見るのは意外と難しい。
今回、
Java
C#
Go
Python
そして C++
で 同じ条件・同じサイズ（512MB） のメモリを確保し、
1ページずつタッチして WS / PF を実測してみた。
結論から言う。
Windows のメモリ管理を“そのまま”観測できたのは C++ だけだった。
検証環境
OS: Windows 11 (x64)
メモリ確保サイズ: 512MB
ページサイズ: 4KB
API:
VirtualAlloc
GetProcessMemoryInfo
1MB ごとにログ出力
C++ 実装概要
C++ では VirtualAlloc で確保した生メモリを
そのままポインタで 1 ページずつ読み出す。
for (size_t i = 0; i < SIZE; i += 4096) {
volatile char x = buf[i];
}
余計なランタイムも GC も存在しない。
OS と 1 対 1 で向き合える状態を作る。
実測結果（C++）
Touched 492 MB | WS 496 MB | PF 127308
Touched 493 MB | WS 497 MB | PF 127564
Touched 494 MB | WS 498 MB | PF 127821
Touched 495 MB | WS 499 MB | PF 128077
Touched 496 MB | WS 500 MB | PF 128334
Touched 497 MB | WS 501 MB | PF 128590
Touched 498 MB | WS 502 MB | PF 128847
Touched 499 MB | WS 503 MB | PF 129103
Touched 500 MB | WS 504 MB | PF 129360
Touched 511 MB | WS 515 MB | PF 132181
何が「正しい」のか
Working Set
Touched MB と WS がほぼ 1:1
ページを触った瞬間に WS に反映
遅延・圧縮・最適化なし
Page Fault
512MB / 4KB ≒ 131,072
PF の最終値が 理論値とほぼ一致
増え方も完全に線形
👉 Demand Paging の教科書どおりの挙動
他言語との違い
言語WSの挙動理由C++◎ 完全一致OS直アクセスC◎同上Delphi◎同上Rust◎unsafe で OS 直Go△→◎最適化・GC対策が必要C#○CLR が介在Java△JVM / FFM の制約Python○ctypes 経由
C++ が“速い”からではない。
“正確”だから基準になる。
なぜ C++ が基準になるのか
GC がない
ランタイム管理メモリがない
ヒープ拡張・圧縮がない
OS API の結果を そのまま観測できる
つまり：
C++ は「Windows メモリ管理の実測器」
まとめ
メモリ管理の理解は「理論」より「実測」
その基準として C++ は今も最強
他言語の挙動は
👉 C++ と比べることで初めて意味を持つ
