Applied Information Technology Engineer Exam, Subject A #9 — OS, Virtual Memory, and Deadlock

Revised: 2026-10-21 · Sources checked: 2026-10-21 · Basis: 2026 IPA Applied Information Technology Engineer Examination (AP), Subject A, syllabus Ver.7.2 Disclaimer: This is independent study material written by Motitory Labs. It is not affiliated with, approved by, or endorsed by IPA (Information-technology Promotion Agency, Japan). Exam scope, format, and syllabus may change; always confirm the latest information on IPA’s official site before the exam. Every question here is original and written for this article; no past exam questions are reproduced.

---

Learning index

1. Scope and official syllabus position
2. Program, process, thread
3. Process state transitions
4. Scheduling and the round-robin trace
5. Virtual memory and paging
6. FIFO and LRU page-replacement trace
7. Thrashing
8. Deadlock
9. Terminology table (KO/JA/EN)
10. Quick sheet
11. Common traps
12. Five original practice questions
13. Self-check
14. 1/3/7-day review plan
15. Official source and syllabus mapping

---

1. Scope and official syllabus position

This installment covers the following items under syllabus Ver.7.2 “Major category 2: Computer systems / Middle category 5: Software / 1. Operating systems” (exact mapping in section 15).

• (2) OS functions and structure — process management, virtual memory management, multiprogramming
• (4)① Tasks and state transitions — process, thread, ready/running/waiting states, dispatcher
• (4)② Multiprogramming and scheduling — FCFS, SJF, priority, round robin, time quantum, resource starvation, mutual exclusion control
• (7)② Virtual memory management — DAT, TLB, page fault, page-in/out, demand paging, LRU, FIFO, thrashing, working set

Deadlock is not listed among the syllabus term examples; it is treated here as the resource-allocation consequence of the “synchronization and mutual exclusion control” scope in (4)②. File systems, I/O, distributed OSes, database transaction deadlocks, and kernel-specific behavior are out of scope.

---

2. Program, process, thread

Item	Meaning	Key point
Program	Instructions and data stored on disk, etc.	Static “executable”
Process	A running instance of a program	Unit to which the OS assigns an address space and resources (open files, etc.)
Thread	A flow of execution inside a process (lightweight process)	Often the unit the CPU scheduler runs

• Threads in the same process normally share the address space (code, data, heap) and resources such as open files.
• Each thread has its own program counter, register context, and stack.
• Because memory is shared, creation and switching are usually cheaper than for processes, but concurrent updates to shared data cause race conditions, so mutual exclusion (mutexes, semaphores, etc.) and synchronization are still required.
• Thread implementation (user-level vs kernel-level) and the scheduling unit vary by OS; avoid absolute “always” claims.

---

3. Process state transitions

Basic three-state model:

             dispatch
   Ready  ───────────────▶  Running
          ◀───────────────
     ▲   preemption / quantum expiry   │
     │                                 │ I/O request / wait for event
     │        event completes          ▼
     └──────────────────────────── Waiting (Blocked)

• Dispatch: the dispatcher picks one task from the ready queue and gives it the CPU → running.
• Preemption: the running task loses the CPU because its quantum expires or a higher-priority task appears → it returns to ready (not waiting).
• Waiting (blocked): waiting for an event such as I/O completion. It cannot run even if the CPU is idle.
• Waiting → ready: when the event completes, the task does not run immediately; it re-enters the ready queue and waits for dispatch. So “waiting” does not mean “ready”, and there is no direct waiting → running transition in the basic model.

---

4. Scheduling and the round-robin trace

Policy	Preemptive?	Selection	Characteristics / risks
FCFS	Non-preemptive	Arrival order	Simple; short jobs can wait behind a long job (convoy effect)
SJF (non-preemptive)	Non-preemptive	Shortest (predicted) CPU burst	Tends to reduce average waiting time; long jobs risk starvation; requires burst estimation
Priority	Either	Priority	Low-priority tasks risk starvation → mitigated by aging (raise priority with waiting time)
Round robin (RR)	Preemptive	Arrival order + time quantum	Fair responsiveness; too small a quantum raises context-switch overhead, too large approaches FCFS

Always state when tracing: arrival times, CPU bursts, context-switch cost, tie-breaking for simultaneous arrivals, quantum, and the initial ready queue. Different assumptions give different answers.

Formulas: turnaround = completion time − arrival time; waiting time = turnaround − CPU burst (when there is no I/O).

Mandatory trace: RR, quantum = 2

Assumptions: P1, P2, P3 all arrive at t=0 in the order P1→P2→P3; CPU bursts 5/3/1; quantum 2; zero context-switch cost; no I/O; no new arrivals. A process that uses its full quantum and still has work goes to the tail of the queue.

Time	Event	Runs	Remaining after slice	Ready queue (head→tail) after slice
0	Initial queue [P1, P2, P3]	P1 0–2	P1=3	[P2, P3, P1]
2	P1 preempted → tail	P2 2–4	P2=1	[P3, P1, P2]
4	P2 preempted → tail	P3 4–5	P3=0 (done t=5)	[P1, P2]
5	P3 finishes before quantum ends	P1 5–7	P1=1	[P2, P1]
7	P1 preempted → tail	P2 7–8	P2=0 (done t=8)	[P1]
8	P2 finishes	P1 8–9	P1=0 (done t=9)	[]

Gantt: P1 0–2 | P2 2–4 | P3 4–5 | P1 5–7 | P2 7–8 | P1 8–9

Process	Burst	Completion	Turnaround	Waiting (turnaround − burst)
P1	5	9	9	4
P2	3	8	8	5
P3	1	5	5	4
Total / average			22 / 7.33	13 / 13/3 ≈ 4.33

Note: FCFS under the same assumptions happens to give the same average waiting time, (0+5+8)/3 = 13/3. Do not identify a policy from an average alone; check the timeline. Non-preemptive SJF would run P3→P2→P1 with waiting 4/1/0 (for P1/P2/P3), average 5/3 ≈ 1.67.

---

5. Virtual memory and paging

• Virtual pages / page frames: the virtual address space is split into fixed-size pages; real memory into page frames of the same size.
• Page table and address translation (DAT): virtual address = (page number, offset). The page table maps page number → frame number; the offset is appended to form the real address. Hardware (the MMU) does this dynamically.
• TLB: a cache of recent address translations (page number → frame number). It is not a cache of data or page contents. A TLB miss is resolved by consulting the page table and is a different concept from a page fault.
• Demand paging: a page is loaded into real memory only when it is referenced.
• Page fault: a synchronous processor exception (fault) caused when the current instruction references a page not in real memory; it is not an asynchronous hardware interrupt. The OS exception handler reads the page from secondary storage (page-in). If there is no free frame, it selects and evicts a victim.
• Dirty-page caveat: if the victim was modified (dirty) since it was loaded, it must be written back to secondary storage—a page-out/write-back. A clean page with a valid backing copy can be discarded without a write. So “every eviction always causes a page-out write” is inaccurate.

FIFO vs LRU

Policy	Victim	On a hit
FIFO	Page loaded earliest	Load order does not change
LRU	Page least recently used	The page’s recency is refreshed

LRU tends to fault less than FIFO for many reference patterns, but this is not guaranteed; results depend on the reference string and frame count.

---

6. FIFO and LRU page-replacement trace

Assumptions: 3 frames, initially empty; reference string 1, 2, 3, 1, 4, 1, 2, 5; no prefetch; one reference at a time; FIFO deterministically evicts the oldest-loaded page; LRU evicts the exact least-recently-used page (no ties). Empty frames are filled without eviction. Frame columns are slot positions (the new page takes the evicted page’s slot).

FIFO

#	Ref	Result	Evicted	Frames [slot1, slot2, slot3]	Load order (oldest→newest)
1	1	Fault	–	[1, -, -]	1
2	2	Fault	–	[1, 2, -]	1, 2
3	3	Fault	–	[1, 2, 3]	1, 2, 3
4	1	Hit	–	[1, 2, 3] (unchanged)	1, 2, 3 (unchanged)
5	4	Fault	1	[4, 2, 3]	2, 3, 4
6	1	Fault	2	[4, 1, 3]	3, 4, 1
7	2	Fault	3	[4, 1, 2]	4, 1, 2
8	5	Fault	4	[5, 1, 2]	1, 2, 5

FIFO page faults = 7 (the only hit is reference 4).

LRU

#	Ref	Result	Evicted	Frames [slot1, slot2, slot3]	Recency (least→most recent)
1	1	Fault	–	[1, -, -]	1
2	2	Fault	–	[1, 2, -]	1, 2
3	3	Fault	–	[1, 2, 3]	1, 2, 3
4	1	Hit	–	[1, 2, 3]	2, 3, 1 (1 refreshed)
5	4	Fault	2	[1, 4, 3]	3, 1, 4
6	1	Hit	–	[1, 4, 3]	3, 4, 1
7	2	Fault	3	[1, 4, 2]	4, 1, 2
8	5	Fault	4	[1, 5, 2]	1, 2, 5

LRU page faults = 6. Evictions: 2 at the reference to 4, 3 at the second reference to 2, 4 at the reference to 5. Final frames [1, 5, 2].

Why they differ: the hit on page 1 (reference 4) changes nothing under FIFO, so page 1 is evicted at the next fault; under LRU it refreshes page 1, which survives, making reference 6 a hit.

---

7. Thrashing

• Definition: page faults and page-in/out become excessive and continuous, so the CPU spends its time waiting on paging instead of useful work, and throughput and CPU utilization collapse.
• Cause: a high degree of multiprogramming leaves each process with fewer frames than its actively used working set.
• Vicious circle: adding more processes because CPU utilization looks low makes frames even scarcer. Adding processes does not help.
• Mitigations: reduce the degree of multiprogramming (suspend or swap out some processes), allocate enough frames for working sets, adjust allocation with working-set or page-fault-frequency (PFF) control, add real memory.
• Changing the replacement algorithm alone does not necessarily cure thrashing; the root cause is insufficient frames.

---

8. Deadlock

8.1 The four necessary (Coffman) conditions

1. Mutual exclusion: a resource can be used by only one process at a time.
2. Hold and wait: a process holds resources while waiting for others.
3. No preemption: held resources cannot be forcibly taken away.
4. Circular wait: processes wait on each other’s resources in a cycle.

All four are necessary together for deadlock to be possible. Therefore structurally denying at least one of them prevents deadlock. Conversely, a system that permits all four does not necessarily deadlock; it merely leaves the possibility open.

8.2 Three strategies — different concepts

Strategy	Idea	Example	Cost / prerequisite
Prevention	Design so one condition can never hold	Global ordering of resources, acquire only in ascending order → no circular wait. Request all resources at once → no hold-and-wait	Lower utilization, design constraints
Avoidance	On each request, dynamically check whether the resulting state is safe; grant only if safe	Banker’s algorithm	Each process must declare its maximum claim in advance; checking overhead
Detection & recovery	Allow deadlock; detect it via a wait-for or resource-allocation graph, then recover	Abort processes, roll back, preempt resources where feasible	Detection frequency; lost work on recovery

Wait-for graph caveat: under the assumption that each resource type has a single instance, a cycle in the wait-for graph means deadlock. With multiple instances, a cycle may exist without deadlock, so a cycle alone is not sufficient and a detection algorithm is needed.

8.3 Mandatory example: safe-state check (one resource type, 10 units total)

Process	Allocated	Max	Need (max − allocated)
P1	3	7	4
P2	2	4	2
P3	2	5	3

Total allocated 7, available = 10 − 7 = 3.

1. Available 3 ≥ P2 need 2 → P2 can finish and release; available 3 + 2 = 5
2. Available 5 ≥ P1 need 4 → P1 finishes; available 5 + 3 = 8
3. Available 8 ≥ P3 need 3 → P3 finishes; available 8 + 2 = 10

A completion order P2 → P1 → P3 (available 3→5→8→10) exists, so the current state is safe. Note that we cannot start with P1 (need 4 > available 3).

This demonstrates only that the current state is safe; it does not mean that granting any future request unconditionally can never lead to deadlock. Avoidance re-checks safety on each later request and defers grants that would lead to an unsafe state. Also, an unsafe state is not itself a deadlock; it is a state where deadlock can no longer be ruled out.

---

9. Terminology table (KO/JA/EN)

한국어	日本語	English
프로세스	プロセス	process
스레드(경량 프로세스)	スレッド（軽量プロセス）	thread (lightweight process)
실행 가능 상태	実行可能状態	ready state
실행 상태	実行状態	running state
대기 상태(블록)	待ち状態	waiting (blocked) state
디스패치 / 디스패처	ディスパッチ / ディスパッチャ	dispatch / dispatcher
선점 / 비선점	プリエンプティブ / ノンプリエンプティブ	preemptive / non-preemptive
타임 퀀텀(타임 슬라이스)	タイムクウォンタム（タイムスライス）	time quantum (time slice)
라운드 로빈	ラウンドロビン	round robin
선착순	到着順（FCFS）	first-come, first-served
최단 작업 우선	SJF（処理時間順）	shortest job first
기아(스타베이션) / 에이징	リソーススタベーション / エージング	starvation / aging
배타 제어 / 동기 제어	排他制御 / 同期制御	mutual exclusion control / synchronization
문맥 교환	コンテキスト切替え	context switch
페이지 / 페이지 프레임	ページ / ページフレーム	page / page frame
동적 주소 변환	動的アドレス変換（DAT）	dynamic address translation
TLB(주소 변환 버퍼)	TLB（アドレス変換バッファ）	translation lookaside buffer
페이지 폴트	ページフォールト	page fault
페이지 인 / 페이지 아웃	ページイン / ページアウト	page-in / page-out
디맨드 페이징	デマンドページング	demand paging
페이지 교체	ページリプレースメント（ページ置換え）	page replacement
워킹 셋	ワーキングセット	working set
스래싱	スラッシング	thrashing
교착상태	デッドロック	deadlock
상호 배제 / 점유 대기 / 비선점 / 순환 대기	相互排除 / 保持と待機 / 横取り不可 / 循環待ち	mutual exclusion / hold and wait / no preemption / circular wait
예방 / 회피 / 탐지·회복	予防 / 回避 / 検出・回復	prevention / avoidance / detection & recovery
안전 상태 / 안전 순서	安全状態 / 安全系列	safe state / safe sequence
은행원 알고리즘	銀行家のアルゴリズム	Banker’s algorithm
대기 그래프	待ちグラフ	wait-for graph

---

10. Quick sheet

• Threads: (normally) share address space and resources; own PC, registers, stack. Sharing means mutual exclusion is needed.
• States: running→ready (preemption), running→waiting (I/O), waiting→ready (event done), ready→running (dispatch). No direct waiting→running.
• Turnaround = completion − arrival; waiting = turnaround − burst.
• RR (5/3/1, q=2): completion 9/8/5, waiting 4/5/4, average 13/3 ≈ 4.33.
• Starvation: risk in SJF and priority → aging.
• TLB = translation cache (not a data cache).
• FIFO: a hit keeps order. LRU: a hit refreshes recency.
• 1,2,3,1,4,1,2,5, 3 frames: FIFO 7, LRU 6.
• Thrashing → lower multiprogramming, secure working sets, PFF. Adding processes worsens it.
• Deadlock conditions: mutual exclusion, hold and wait, no preemption, circular wait — break one to prevent.
• Prevention (structural) ≠ avoidance (dynamic safety check, declared max) ≠ detection & recovery (after the fact).
• Wait-for cycle = deadlock only under the single-instance assumption.
• Safe example: available 3, P2→P1→P3, 3→5→8→10.

---

11. Common traps

1. Confusing waiting with ready — a waiting process cannot run even if the CPU is idle.
2. Sending a preempted process to waiting — after preemption it is ready.
3. Skipping queue updates in RR — a process whose quantum expires goes to the tail; a burst shorter than the quantum ends early and the next process is dispatched immediately.
4. Computing waiting time as “time until first run” — total waiting is turnaround − burst (P2 is 5, not 2).
5. Treating the TLB as a data cache or page store — it stores translations only.
6. Refreshing order on a hit under FIFO — that turns the calculation into LRU.
7. “LRU always faults less than FIFO” — a tendency, not a guarantee.
8. Adding processes during thrashing to raise CPU utilization — counterproductive.
9. Using prevention, avoidance, and detection as synonyms — they differ in timing and prerequisites.
10. Treating any cycle as deadlock with multi-instance resources — valid only under the single-instance assumption.
11. Reading “safe state” as “deadlock-free forever” — it is a judgment about the current state only.

---

12. Five original practice questions

All questions are original and written for this article. No past exam questions are used.

Question 1 (round robin)

Processes P1, P2, P3 arrive in the ready queue at time 0 in the order P1, P2, P3. Their CPU bursts are 5, 3, and 1. They are scheduled by round robin with a time quantum of 2; context-switch time is 0, there is no I/O and no new arrival, and a process that uses its whole quantum goes to the tail of the queue. Which statement is correct?

• ア The completion order is P1 → P2 → P3.
• イ P2’s waiting time is 5, and the average waiting time is 13/3.
• ウ P3 completes at time 3.
• エ The average waiting time is 5/3.

Answer: イ

Derivation: queue [P1,P2,P3] → P1 0–2 (3 left) → [P2,P3,P1] → P2 2–4 (1 left) → [P3,P1,P2] → P3 4–5 done → [P1,P2] → P1 5–7 (1 left) → [P2,P1] → P2 7–8 done → [P1] → P1 8–9 done. Completion 9/8/5; waiting = turnaround − burst = 4/5/4; total 13; average 13/3 ≈ 4.33.

• ア: Wrong. The actual completion order is P3 (5) → P2 (8) → P1 (9). P1→P2→P3 is the FCFS completion order.
• ウ: Wrong. P3 runs at 4–5 after P1 and P2 each run for 2, completing at time 5.
• エ: Wrong. 5/3 is the average for non-preemptive SJF (P3→P2→P1, waiting P1/P2/P3 = 4/1/0).

Question 2 (FIFO and LRU)

With 3 page frames (initially empty), the reference string 1, 2, 3, 1, 4, 1, 2, 5 is processed one reference at a time. There is no prefetch; FIFO evicts the page loaded earliest and LRU evicts the page referenced least recently (no ties). No eviction occurs while a frame is empty. Which pair (FIFO faults, LRU faults) is correct?

• ア (6, 6)
• イ (7, 7)
• ウ (6, 7)
• エ (7, 6)

Answer: エ

Derivation: FIFO states: [1,-,-] F, [1,2,-] F, [1,2,3] F, hit (unchanged), [4,2,3] F (evict 1), [4,1,3] F (evict 2), [4,1,2] F (evict 3), [5,1,2] F (evict 4) → 7. LRU: three initial faults, 1 hit (refresh 1), 4 fault (evict 2) → [1,4,3], 1 hit, 2 fault (evict 3) → [1,4,2], 5 fault (evict 4) → [1,5,2] → 6.

• ア: Wrong. Refreshing order on a hit under FIFO (i.e. computing it like LRU) gives 6.
• イ: Wrong. Not refreshing recency on a hit under LRU gives the FIFO result, 7.
• ウ: Wrong. The two values are swapped.

Question 3 (thrashing)

In a multiprogramming environment, page faults surge and CPU utilization drops sharply. The cause is judged to be that each process has fewer page frames than its working set. What is the most appropriate measure?

• ア Reduce the degree of multiprogramming so that each process gets enough frames for its working set.
• イ Increase the number of running processes to raise CPU utilization.
• ウ Increase the number of TLB entries to eliminate page faults.
• エ Switching page replacement from FIFO to LRU will always resolve the problem regardless of frame shortage.

Answer: ア

Derivation: Thrashing occurs when frames are fewer than the actively used page set (working set), so paging never stops. The remedy is to lower the degree of multiprogramming (suspend or swap out processes) and allocate frames based on working set or page-fault frequency.

• イ: Wrong. More processes mean even fewer frames per process, worsening thrashing.
• ウ: Wrong. The TLB caches address translations; it cannot eliminate page faults, which happen because the page is not in real memory.
• エ: Wrong. Changing the algorithm may help somewhat, but it does not “always” fix the root cause (frame shortage), and LRU is not always superior.

Question 4 (deadlock strategy)

Every resource is given a global order number, and each process must acquire resources only in ascending number order. Which description of this method is correct?

• ア It is an avoidance method that checks for a safe state on every allocation.
• イ It is a prevention method that denies the mutual exclusion condition.
• ウ It is a prevention method that denies the circular wait condition.
• エ It is a detection-and-recovery method that periodically searches the wait-for graph for cycles.

Answer: ウ

Derivation: If everyone requests in ascending order, any wait goes from a holder of lower-numbered resources toward a higher-numbered one, so no cycle can form. This structurally removes circular wait — prevention.

• ア: Wrong. Avoidance checks safety dynamically per request and requires declared maximum claims; an ordering rule is a static design constraint.
• イ: Wrong. Each resource is still used by one process at a time; mutual exclusion remains.
• エ: Wrong. Detection and recovery lets deadlock happen and handles it afterward; this method prevents it from occurring.

Question 5 (safe state)

There is one resource type with 10 units in total. Current allocated/maximum claims are P1 = 3/7, P2 = 2/4, P3 = 2/5. Each process, once granted up to its maximum, completes and releases everything it holds. Which statement about this state is correct?

• ア It is unsafe because available 3 is less than P1’s remaining need of 4.
• イ It is safe, and P1 → P2 → P3 is a safe sequence.
• ウ Because it is safe, no deadlock can occur no matter which future requests are granted.
• エ It is safe; completing in the order P2 → P1 → P3 makes available 3 → 5 → 8 → 10.

Answer: エ

Derivation: available = 10 − (3+2+2) = 3. Needs: P1 4, P2 2, P3 3. P2 (2 ≤ 3) finishes → 5; P1 (4 ≤ 5) finishes → 8; P3 (3 ≤ 8) finishes → 10. A safe sequence exists, so the state is safe.

• ア: Wrong. Safety asks whether some order lets everyone finish. P1 cannot go first, but starting with P2 works.
• イ: Wrong. P1’s need 4 > available 3 at the start, so P1 cannot go first.
• ウ: Wrong. Safety is a judgment about the current state. Granting requests later without checking can lead to an unsafe state, which is why avoidance re-checks every request.

---

13. Self-check

• I can distinguish program, process, and thread, and say what threads share and what they own.
• I can say which state a preempted process and an I/O-waiting process each go to.
• I can replay the RR (5/3/1, q=2) trace including queue contents and derive average waiting 13/3.
• I can name policies prone to starvation and explain aging.
• I can explain the relationship among TLB, page table, and page fault.
• I can reproduce FIFO 7 and LRU 6 step by step for 1,2,3,1,4,1,2,5.
• I can explain the cause and remedies of thrashing, and why “add processes” is wrong.
• I can state the Coffman conditions and distinguish prevention, avoidance, and detection with examples.
• I can state when a wait-for-graph cycle implies deadlock.
• I can derive the safe sequence P2→P1→P3 and explain the limits of “safe state”.

---

14. 1/3/7-day review plan

• Day 1: Without the quick sheet, redraw the RR timeline and the FIFO/LRU tables on blank paper. Solve Q1–Q2 and check the numbers.
• Day 3: Write out the state diagram, the Coffman conditions, and the prevention/avoidance/detection table as if teaching. Solve Q3–Q4 and explain aloud why each wrong option fails.
• Day 7: Change the assumptions (e.g. quantum 3, 4 frames, available 2) and trace them yourself. Solve Q5 and re-check all 11 common traps.

---

15. Official source and syllabus mapping

Official source: IPA, “応用情報技術者試験（レベル3）シラバス Ver.7.2” (Applied Information Technology Engineer Examination (Level 3) Syllabus Ver.7.2) URL: https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf Checked: 2026-10-21 (printed PDF pages 23–24)

Section here	Syllabus Ver.7.2 position	Term examples
2. Program, process, thread	Major 2 / Middle 5 / 1. オペレーティングシステム / (4) タスク管理 ① タスクと状態遷移	軽量プロセス, プロセス, スレッド
3. State transitions	Same, (4)①	実行可能状態, 実行状態, 待ち状態 (role of the dispatcher)
4. Scheduling, RR	Same, (4)② 多重（マルチ）プログラミング（マルチタスク）とスケジューリング	プリエンプティブ, ノンプリエンプティブ, タイムスライス, 優先順, ラウンドロビン, SJF, FCFS, タイムクウォンタム, リソーススタベーション, ディスパッチ
2 & 8. Synchronization/exclusion, deadlock	Same, (4)② (need for and implementation of 同期制御・排他制御)	排他制御 ※Deadlock is not a listed term example; derived from this scope
1 & 5. OS functions, virtual memory overview	Same, (2) OSの機能と構成	仮想記憶管理, プロセス管理, 多重（マルチ）プログラミング
5–7. Paging, replacement, thrashing	Same, (7) 記憶管理 ② 仮想記憶管理	DAT, TLB, ページフォールト, ページイン, ページアウト, デマンドページング, ページリプレースメント, LRU, FIFO, スラッシング, ワーキングセット

Again: this material is not endorsed by IPA, and the exam system and syllabus may change. Check IPA’s official site for the latest information.