Memory Reduction Workbook

Memory reduction workbook: physical pages, game headroom and removal decisions

This page turns the measured comparison into a removal worklist. Read Memory-Comparison-and-Removal-Guide for the three-BIOS comparison; use SpiritBoot-Main-Physical-Ownership for every physical interval and SpiritBoot-Main-Emitted-Extent-Ledger for every owned function extent. The complete public-entry comparison is Memory-Three-BIOS-Public-API-Comparison. This workbook adds the decision, lifetime, failure and measurement questions that raw size lists cannot answer.

1. Exactly which numbers are being compared

The retained plain-main allocation/lifetime checkpoint is product revision f60f8de605cbbdce2f22e4bc3489e1c1487dcb59, reconstructed tree 6e7666c73c916a235d29ec793dc9ee0920df299b. The retained Complex 4627 checkpoint ran the same public allocation/lifetime procedure. These are completed synthetic allocation checkpoints, not peak memory measurements from a game. Retail 5838 did not finish the public probe; its final free capacity remains unknown.

Checkpoint / candidate	Unavailable pages	Unavailable KiB	Gap to retained Complex	Gap as fraction of installed 64 MiB
Complex retained final checkpoint	158	632	0	0%
SpiritBoot plain-main final checkpoint	332	1,328	696 KiB	1.0620%
Pool-only candidate final checkpoint	316	1,264	632 KiB	0.9644%
ROM-only bound capture	244	976	344 KiB	0.5249%
ROM + pool bound integration capture	228	912	280 KiB	0.4272%

The denominator is 65,536 KiB. A percentage of installed RAM is not a percentage of firmware overhead or remaining free capacity. At a title checkpoint with only 1 MiB free, a 632 KiB difference would represent a substantial fraction of the remaining margin. That example is illustrative; no such 1 MiB game checkpoint is established here.

Only the first two rows are the retained baseline comparison. Candidate rows retain their individual source/build/qualification limits. The measured combined row exists independently; it is not assumed by adding two unrelated savings. No candidate saving is promoted into released main merely because it appears in this table.

The initial plain-main availability gap is 572 KiB, or 0.8728% of installed RAM. Initial and post-activity counts differ. The extra 124 KiB retained after this procedure is a lifetime clue, not a second copy of the image gap.

2. Physical owner challenge ledger

Every owner below comes from the disjoint 332-page main census. The challenge column describes independent SpiritBoot design work. It does not reconstruct proprietary implementation bodies.

Physical owner	Pages / KiB	Why it is charged	Reduction mechanism to investigate	Proof required before recovery
Kernel headers	1 / 4	Live loaded-image metadata	Retain only metadata actually needed by runtime consumers	Loader, exception, export, diagnostics and reset consumers identified; no dangling image references
Kernel .text	81 / 324	Resident executable backing	Smaller exclusive service closures; independently qualified cold-code placement	New linked layout, all exports/callback roots, fault and reset paths, pages actually returned
Kernel .data	1 / 4	Mutable globals	Smaller state or fewer live service instances	No ABI layout change, initialization/update synchronization preserved
Kernel .rdata	7 / 28	Constants, tables, readonly metadata	ROM placement or representation change	Relocations, complete access patterns, code/data shared-page packing and cost
Kernel .bss	11 / 44	Writable zero-initialized state, including embedded stacks	Remove live dependencies or reduce private state	Exact body sizes and consumers; idle/fault stacks remain accounted
Kernel PAGE	1 / 4	Resident backing despite section name	Establish actual pageable/discardable lifetime, if one exists	Section naming alone grants no reclamation permission
Page-supply links	16 / 64	Per-frame free/owner representation	Compact common state with bounded exceptional representation	Relocation ownership, deferred free, aliasing and allocation failure behavior
Page-supply pin state	8 / 32	Per-frame pin counts and flags	Reduce representation cost without expensive access	Overflow, duplicates, rollback, pin/unpin throughput, no allocation under PFN lock
Pool metadata	3 / 12	Authoritative pool runs/bitmap	Metadata proportional to populated regions	Interior query/free, large allocations, region transitions, synchronization and fixed upper bounds
Pool window	86 / 344	Live objects, retained slabs, cache and reserve backing	Reuse whole empty backing; selected page-efficient geometry	Live contents/capacities, ordinary/reserved domains, mixed lifetimes and repeated pressure
Other system-PTE allocations	37 / 148	Stack mappings in this capture	Remove unnecessary live execution contexts	Thread identities, stack depth and cross-queue blocking proof
Installed page tables	17 / 68	Actual live mapping structures	Avoid unnecessary mappings or retire genuinely empty tables	Every PDE/alias retired, no stale TLB or callback mapping, reset reconstruction
Residual PFN backing	1 / 4	Separate physical metadata backing	Identify remaining consumer and representation	Source owner plus mapped aliases; do not relabel it as free scratch
Working-set backing	1 / 4	Live working-set structure	Smaller shared/fixed-platform representation if compatible	Title/runtime consumers, growth, failure and teardown
Low boot reservations	6 / 24	Remaining low-memory protected structures	Only retire a demonstrably obsolete lifetime	Interrupt/PCR/bootstrap/reset and persistence references accounted
NV 2 A padding	16 / 64	Hardware reservation	No ordinary firmware saving assigned	Preserve GPU-instance-memory contract; compare like hardware configurations
Live contiguous allocations	2 / 8	Workload-dependent physical allocations	Release at real last use; preserve title requests	Owner, alignment, persistence and consumer completion
Title virtual backing	37 / 148	Authored workload allocations	No saving by denying requested title memory	Same allocation success, capacity, contents and cleanup
Total	332 / 1,328	One charge per unavailable physical page

Rows are disjoint physical owners. Cache buffers, thread structures and smaller objects are nested explanatory owners; they must not be added to this total again. A shared physical page has one charge even if several virtual aliases map it.

3. What the small reference image actually establishes

Complex has 45 image pages / 180 KiB at the completed checkpoint. SpiritBoot has 102 / 408 KiB. The 57-page image difference is therefore real for this pair. Complex's remaining 113 unavailable pages / 452 KiB are an exact remainder, not a complete private heap/PFN/cache ownership ledger.

The references have approximately 153–157 KiB of retained executable-section content versus SpiritBoot's 328,932 bytes. That comparison supports investigating retained service breadth. It does not establish that a given SpiritBoot API can be deleted or replaced by a reference-sized stub.

The proprietary entry walks contain shared tails, interior entries and incomplete indirect-call coverage. SpiritBoot's 1,438 compiler extents include inlining/padding. These are different attribution methods. Use public ABI ordinal matches to compare entry footprint, then examine owned-source closure to estimate a real subsystem change. Do not sum overlapping reference walks.

Complex's sampled runtime public entries are RAM-backed. No retained workload observation proves a broad direct-ROM runtime strategy. Retail's expected approximately 180 KiB post-INIT image is a layout estimate; its captured 612 KiB image still included initialization pages. Neither observation supports claiming a finished retail game-capacity comparison.

4. Removal candidate record: required fields

Each candidate should have one record, linked to a focused issue/PR:

Field	Required detail
Build identity	Product commit, reconstructed source tree, firmware and matching symbol identity
Owner	Physical intervals, virtual aliases, source allocation or emitted section, exact checkpoint
Entry roots	Public ABI, saved driver callbacks, timers/DPCs, queues, interrupt/fault handlers and return sites
Lifetime	First publication, last legal use, drain/retirement sequence, reset/save-load reconstruction
Exclusive closure	Code/data retained solely by this service; shared callees explicitly excluded
Page packing	Neighboring contents, alignment and actual pages released by counterfactual build
Runtime cost	Useful work, waits, mapping/invalidation costs, per-operation distribution and title impact
Capacity	Total free pages, largest relevant allocatable contiguous run, pool backing and pressure failures
Compatibility	Exact affected contracts and old behavior retained for unsupported/exceptional paths
Decision	Implement, qualify, hold, reject, or defer; measured reason and remaining gate

An uncalled function during a menu recording remains a candidate for investigation, not dead code. A reset-only callback can retain a body indefinitely even when normal gameplay never executes it. A boot callback is discardable only after no queued work, completion, returning frame or saved pointer can reach it.

Three ways to save bytes and their physical consequences

1. Remove a dependency: code, data, objects and a worker may all disappear. Count the rebuilt exclusive closure and runtime allocations separately.
2. Move readonly content: ROM backing can release RAM pages, but introduces mapping/access and reset contracts. Mutable/self-modified content needs RAM.
3. Recycle runtime backing: fewer pages remain committed after activity, without changing the image. Count settled and peak savings separately.

Moving a function between two resident sections, reducing an object that still occupies one whole page, or reducing compressed ROM size can recover zero physical RAM pages. Every result must state whether it saved image bytes, resident pages, runtime backing, allocation latency or title performance.

5. Actual game memory pressure: what is known and missing

The current allocation probe proves capacity and ownership for its own procedure. The Conker/PGR 2 release campaigns collect frame/CPU data, but their retained results are not a title-wide minimum-free-page trace. Clean boot/menu progression establishes those scenes work; it cannot establish the peak during a later race, level load or save.

One historical Def Jam checkpoint does contain a direct owned-kernel counter observation: at Press START, 1,377 lower-bank pages / 5.3789 MiB were available in the physical-128 MiB / upper-64-reserved compatibility profile. Total physical pages were 32,768; physical free including reserved capacity was 17,341. This is not an ordinary 64 measurement, a Complex comparison, a peak, or proof that Def Jam will remain safe later. See the qualified compatibility record. Lower-bank occupancy includes firmware/hardware as well as title allocations; it must not be labeled title-owned memory alone.

The archived observation demonstrates why public title-available capacity and total physical free capacity must be recorded separately in the reserved profile. Reporting 67+ MiB free would misrepresent the usable game bank at that checkpoint.

Minimal decisive game-pressure experiment

Use ordinary 64, unchanged EEPROM/HDD semantics and the existing authored inputs. Begin with PGR 2, Conker and the known allocation-sensitive Def Jam route. Menu, first playable scene, heavy load/transition, ordinary save/load and repeated reset are distinct checkpoints. Human play is needed where the existing route cannot reach the suspected peak reproducibly.

Record the following from the actual owned kernel, using a separately identified diagnostic capture:

Measurement	What it answers	Limitation
Current available pages	How much capacity is available now?	A sparse sample can miss a brief trough
Minimum available pages	Did a load/allocation burst approach exhaustion?	Reset the minimum only at a declared boundary; include diagnostic overhead
Allocated/pinned/contiguous populations	Which allocation type consumes capacity?	Category counters may overlap; validate against physical owners
Relevant largest contiguous free run	Can the next GPU/DMA/contiguous request succeed?	Generic free-page count cannot answer this
Allocation failures and requested size/alignment	Does the shortage cause behavior rather than only a small number?	Failures can also be invalid requests or domain restrictions
Pool committed and live capacity	Is capacity occupied by live objects or retained empty backing?	Public pool count may differ from actual mapped pages
Reset and post-transition recovery	Does occupancy accumulate or return to baseline?	Compare the same phase and workload history
Useful frame progress and frame-time tails	Does reducing memory pressure improve the workload?	Diagnostic overhead must not enter ordinary release performance claims

Prefer read-only observation of existing counters before adding firmware instrumentation. A new high-water counter belongs in a diagnostic build and needs quantified update/sampling overhead. Do not add a guest API call per frame or a synchronous per-allocation log to the release BIOS. If timing is altered, retain that run as discovery rather than the performance arm.

A small reserve test that intentionally removes capacity is a separate authored procedure. It must not silently change the benchmark or be interpreted as the game's normal demand. Do not claim the title needs a reserve that was created only by the test.

Interpreting the result

• Comfortable aggregate and contiguous headroom, no failures: the current footprint gap is unlikely to explain this tested scene's problem. A smaller kernel remains a compatibility objective; a disruptive rewrite is not justified by that scene alone.
• Aggregate free pages remain high but contiguous requests fail: investigate placement, relocation and fragmentation before discarding arbitrary code.
• Free capacity falls below the measured gap: parity could change whether that burst succeeds. Preserve the allocation request and show success after the candidate.
• Backing rises across resets/transitions: identify the live owner/leak/retention policy. A smaller initial image can mask accumulation without fixing it.
• CPU/frame tails worsen with a memory candidate: diagnose the active path and complete cost. A synthetic leaf slowdown does not by itself prove a title regression, but it cannot be advertised as a speedup.

No whole-game peak requirement is claimed until these data exist. The approximately 1% installed-RAM gap alone proves neither broad incompatibility nor sufficient headroom.

6. Immediate work order and stopping rules

1. Finish the bounded pool reuse candidate #135. A 64 KiB saving is already measured; release title qualification is still separate. Memory-Pool-Reuse-Cost-and-Attribution records the current repair, actual costs and limitations.
2. Measure actual game headroom at meaningful allocation boundaries. Reuse the current routes and preserve the benchmark definition. Prefer a few attributable captures over a new permanent profiling framework.
3. Specialize retained storage/PnP lifetime (#142). Establish the runtime root and its exclusive closure before changing residency. This is the first architectural code-reduction target, not a promise of a fixed KiB saving.
4. Remove one unnecessary resident execution context (#143), if the blocking proof permits it. Stack reduction must come from ownership rather than blindly shrinking the minimum.
5. Evaluate filesystem closure (#141) and compact PFN state (#144) independently. Keep the known slower packed encoding rejected until another design proves acceptable cost.
6. Keep ROM execution #118 independent. Its larger demonstrated RAM saving still has title/reset/access qualification outstanding. It is not assumed to be the reference's design.

Do not reopen already-reclaimed scratch as a new saving, demand a new long game campaign for every harmless table-layout edit, or combine unrelated runtime changes into one PR. First establish the mechanism and relevant compatibility checks; use title performance tests where the changed lifetime or hot path can materially affect them.

7. Evidence and publication boundary

This page is original numeric/behavioral documentation. Proprietary ROM instruction bodies, memory dumps, firmware images, game assets and private captures are not published. The full numeric inventories have their own build/checkpoint scope. The retained reference investigation is not claimed to be a personnel-separated clean-room reimplementation.

The wiki is the comparison workspace. Experimental traces and raw evidence stay outside product main. A future reduction report must show actual uniquely released pages, same successful title allocations and unchanged required behavior—not merely a smaller binary or a favorable percentage.