{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Policy{{ resultsReady ? simulation.algorithmLabel : '—' }} Frames{{ resultsReady ? simulation.frameCount : '—' }} Trace{{ resultsReady ? `${simulation.selectedStep} / ${simulation.totalSteps}` : '—' }}
Request {{ inputPreviewPage }}
Frames
Victim rule {{ heroPolicyLabel }}
Choose the policy whose exact frame decisions you want to inspect.
Use 1–30 labels. Repeated labels represent repeated requests for the same page.
Both samples are deterministic teaching sequences.
frames
Choose 1–8 initially empty frames.
{{ resultsReady ? `${simulation.selectedStep} / ${simulation.totalSteps}` : '—' }}
Step 0 shows empty frames; later steps expose the selected policy's exact residency decision.
extra
The neutral default is 0. The combined frame count may not exceed 8.
StepPageOutcomeEvictedFrames after requestPolicy evidenceCopy
{{ row.step }}{{ row.page }}{{ outcomeLabel(row.outcome) }}{{ row.evicted === null ? '—' : row.evicted }}{{ formatFrames(row.frames) }}{{ row.policyState }}

The chart renderer is unavailable. Exact totals remain available in the comparison ledger.

AlgorithmHitsFaultsEvictionsHit ratioFaults at {{ simulation.alternateFrameCount }} framesFrame effectCopy
{{ row.label }}{{ row.hits }}{{ row.faults }}{{ row.evictions }}{{ formatPercent(row.hitRatio) }}{{ row.alternateFaults }}{{ frameEffectLabel(row) }}
CPU Scheduling Algorithm Simulator Compare CPU scheduling policies through dispatch traces and ready-queue decisions, including context-switch overhead and per-process timing metrics.
Memory Allocation Algorithm Simulator Compare contiguous memory fit policies through stepwise placements, coalescing and failure reasons alongside external fragmentation metrics.
Banker's Algorithm Deadlock Avoidance Simulator Test Banker’s algorithm states and resource requests with step-by-step safety traces, safe-sequence witnesses, and rollback decisions.
Disk Scheduling Algorithm Simulator Compare classic disk-scheduling policies on one request queue with animated service order, endpoint events, and total head movement.

Virtual memory lets a program use addresses without knowing which physical memory frames currently hold its pages. When a requested page is already resident, the access is a hit. When it is absent, a page fault brings it into memory. If every available frame is occupied, the operating system also needs a replacement policy to choose a resident page to evict.

A page-reference string records requests in their original order. Repeated labels matter because recent and future use are exactly what separate the policies. First-In, First-Out (FIFO) follows arrival order, Least Recently Used (LRU) follows access history, Optimal looks ahead through the complete reference string, and Clock approximates recency with a circular hand and reference bits.

Hit
The requested page is already in one of the frames, so no replacement is needed.
Fault
The requested page is absent. It fills an empty frame or causes an eviction when the frames are full.
Eviction
A resident page leaves a full frame so the faulting page can enter.
Policy state
The queue, recency order, future-use evidence, or Clock bits that justify the next victim choice.

More frames often reduce faults, but that expectation is not universal. FIFO can show Bélády's anomaly, where a particular reference string produces more faults after memory capacity increases. LRU does not show that anomaly because every page held with a smaller frame count remains part of the larger-frame resident set under the same history.

A trace explains policy decisions for one bounded sequence; it does not predict the total cost of a real memory system. Disk or storage latency, dirty-page writes, prefetching, shared pages, translation lookaside buffers, and live workload changes all affect performance beyond the hit and fault counts shown here.

How to Use This Tool:

Keep the reference string and frame count fixed when comparing policies, then change one factor at a time.

  1. Choose a Focus policy whose exact frame decisions you want to follow.
  2. Enter 1 to 30 page labels in Page-reference string, separated by spaces, commas, or line breaks. Each label may contain 1 to 8 letters, numbers, underscores, or hyphens.
  3. Set Page frames from 1 to 8. Frames begin empty, so the first request for each initially absent page is a fault.
  4. Move Trace step from step 0 through the final request. Step 0 shows the empty frames; later steps show the requested page, hit or fault, victim, resulting frames, and policy evidence.
  5. Set Additional-frame comparison from 0 to 3 when you want to compare the same reference string at a larger capacity. The two frame counts together may not exceed 8.

Interpreting Results:

Read the selected trace before comparing totals. A lower fault count is better for this reference string, while the hit ratio expresses the same outcome from the opposite direction. An eviction count can be lower than the fault count because faults that fill empty frames do not evict anything.

The policy comparison uses the same labels and frame count for all four methods. Optimal is an offline lower bound because it can see future requests; it is useful as a benchmark, not as a deployable general-purpose policy. Clock and LRU use different evidence, so similar totals do not mean they made the same victim choices.

A positive fault difference after adding frames means the larger run faulted more often. Treat that as evidence about this policy and sequence, not as a general claim that extra memory hurts performance.

Technical Details:

Each request first checks the resident frames. A hit preserves the frame contents and may update recency or reference-bit state. A fault fills an empty frame if one exists; only a fault with no empty frame invokes the selected eviction rule.

Rule Core:

The victim rule is the main difference among the policies. Ties follow the stable frame or policy order established by the trace.

Policy Victim rule when frames are full State shown in the trace Important limit
FIFOEvict the resident that entered earliest.Oldest-to-newest queueIgnores later reuse and can show Bélády's anomaly.
LRUEvict the resident whose most recent request is oldest.Most-recent-to-least-recent orderUses past access as a predictor of future need.
OptimalEvict the resident used farthest in the remaining string, or one never used again.Next-use position for every residentRequires future knowledge and serves as a lower bound.
ClockAdvance the hand, clearing reference bits of 1, until a frame with bit 0 is found.Hand position and one bit per frameApproximates recency rather than reproducing LRU exactly.

Formula Core:

The hit ratio is the percentage of page requests served by pages already resident. Hits and faults divide the complete reference string, so their counts add to the number of requests.

Hit ratio = hits hits+faults × 100 %

The ratio keeps full precision for comparison and is formatted for display. Fault and eviction totals are integer counts; no timing cost is inferred from them.

Bélády Sequence:

For FIFO, the reference string 1 2 3 4 1 2 5 1 2 3 4 5 produces 9 faults with 3 frames and 10 faults with 4 frames. The additional frame therefore changes the FIFO queue in a way that creates one extra fault. LRU retains the stack property and does not reverse direction on this sequence.

Page labels are compared literally. The simulation accepts 1 to 30 labels, 1 to 8 base frames, and up to 3 additional frames, with a hard combined maximum of 8. Every run is deterministic for the same policy, labels, and frame settings.

References: