Repository navigation
Startup Acceleration
Research date: October 15, 2026. Goal: reduce the wait from launching the large Forge pack to a genuinely usable game, alongside FPS and frame-time improvements, without removing mods, visuals, features, safety checks or save compatibility.
Recommendation: build a measured startup accelerator around reusable work and bounded CPU parallelism first. Add GPU assistance for data that can stay on the GPU, especially texture preparation/upload. A GPU cannot directly run arbitrary Java mod constructors, Mixin transformations or registry callbacks. No startup-speed percentage is established for this pack yet.
This report is based on source inspection, official documentation and a read-only inventory of actual downloaded reference JARs. No local game/launcher configuration was changed. The current unpublished build and exact installed Forge/ModernFix versions still need reconciliation. No paused development worker was resumed.
Inspected pinned sources:
- Hari:
98a85a89cb792d1d335b095ed774cf71773126fc, branchmigration/projectdump-20261004; active overlay takes precedence over the older source tree. - Forge
1.20.x:243490d78001917c7e6ee6e94b45ef98776aa36f, October 15, 2026. This is a source reference, not a claim that the pack has this exact Forge build. - ModernFix
1.20:1df6471ba9ff98c8b031c8978f56ba38baa0c931, October 11, 2026. - DashLoader:
c8cd8b4c4f5f05f68a2f56becf9d721f7d1d23da; architectural reference, not a qualified Forge/Hari drop-in. - Original LazyDFU:
a83ce2f3e7deb429d48134700424b4454f3bee8b; older reference, not a reason to stack another DFU patch on this pack.
The source-file manifest pins 45 inspected files at this snapshot. Downloaded source is not executed or distributed in the research bundle.
Treat startup as several connected workloads, not one progress bar:
- Launcher/authentication, Java process creation and early loader discovery.
- JAR/nested-JAR discovery, metadata/annotation scanning, class transformation and class initialization.
- Registries, mod lifecycle stages and deferred main-thread work.
- Resource discovery, parsing, model dependencies/baking, texture decode/mips/stitching, sound/font initialization.
- Hari shader translation, SPIR-V compilation, native pipeline construction and texture transfers.
- Main menu readiness.
- World selection, datapack/recipe processing, handshake and chunks.
- First usable world frame, first inventory/search, first Create scene, scope/effect and dimension transition.
Record process-start, first-window, menu-interactive, world-join, input-responsive and first-use timestamps. Faster menu display with missing resources or later multi-second stalls is not success. Measure the first few minutes' frame-time tails as well as launch time. Treat resource reload as its own scenario.
Collect CPU samples, allocation/GC, disk reads, locks/waits, worker occupancy and native shader/upload counters. A mostly idle CPU may be waiting on a serialized stage, filesystem, network or deliberately tick-paced handshake; adding threads cannot fix every wait. Concurrent phase durations overlap: do not sum them and call that wall time.
Use local bounded Java Flight Recorder recordings first. Java 17 supports startup recording and configurable recording limits. Keep diagnostics on a drive with headroom and turn them off for matched speed measurements. Do not dump heap contents or launcher credentials into public issues. Oracle JFR
ModernFix offers Spark launch/world-join profiling and the local reload-timing option -Dmodernfix.debugReloader=true. Spark launch profiling can upload reports; its maintainer specifically warns against shipping the enabling switches in a public pack. Use it only deliberately, with the relevant data-sharing approval; do not auto-enable it for everyone. Launch profiling, changelog
Forge already dispatches several lifecycle events concurrently. Registry events remain synchronous, and enqueueWork exists for operations needing the appropriate main-thread phase. Do not run the entire Forge event system in a generic pool. Forge lifecycle contract
However, the inspected BackgroundScanHandler uses a single-thread executor for file.compileContent. Its Scanner parses class metadata with ASM while skipping method code/debug/frames, then calls language-provider visitors. These are separate from mod construction and shader work. BackgroundScanHandler, Scanner
Proposed implementation slice: parse independent class byte streams into per-artifact immutable results in a small bounded pool. Preserve deterministic merge order and run unqualified language-provider callbacks in their existing order/thread context. Prove locator/ZIP filesystem access safety; a custom provider may have mutable state. Do not merely change the executor and assume visitors are thread-safe.
Start with concurrency 1, 2, 4 and 8, bounded by memory and measured CPU/storage capacity. Count total nested work across Forge, resource reload, shader workers and driver threads. More workers can increase allocation, cache misses, disk seeks and GC enough to lose. A phase-aware budget is preferable to separate all-core pools fighting each other.
Forge's existing parallel mod-loading pool is independently controlled by FMLConfig.MAX_THREADS; its workers preserve the context class loader. Keep that behavior in any replacement. ModWorkManager
This needs an early-loader integration point or upstream loader contribution; an ordinary mod initialized after scanning cannot retroactively accelerate that phase. Package invasive loader work separately from renderer-only improvements and fail back to the original scan on unsupported versions.
Cache pure structural results, not arbitrary live Java objects or the side effects of mod initialization. A useful first cache contains class names, inheritance/interface metadata and complete annotation data produced by the known scanner version. Reattach current runtime metadata and invoke required language-provider processing normally.
A valid key needs artifact content identity, nested-artifact path/content, scanner/schema version, loader environment and applicable parsing settings. Preserve the exact data shapes expected by downstream mods. ModernFix's scan-data compactor even retains ArrayList implementations for some annotation values because mods depend on that detail; this warns against casual serialization substitutes. ModFileScanDataCompactor
Use content-addressed per-artifact entries, atomic writes, schema checks, checksums, a byte budget and a bounded number of generations. One changed mod should invalidate its parsed data and affected dependencies, not the entire pack cache. Partial/corrupt cache data must trigger an ordinary scan with useful diagnostics. Preserve error reporting, dependency ordering, nested-JAR semantics, service metadata and signature validation.
Class-transform output caching is a much higher-risk later step. Transformers can inspect other mods, configuration, environment and loading order; some perform side effects. A cache of final bytecode can skip those side effects and become wrong even when the input class bytes are unchanged. Only cache a proven deterministic transformation boundary with a complete environment key. FastStart's older experiment and invalidation caveats
The active UniversalRendererGate already caches its final decision. On a cache miss it walks external JAR classes and nested JARs to inspect direct GL references. Exact inactive-class audits happen before the cache lookup. Therefore, do not pitch a first-ever compatibility cache or bypass this gate for speed.
Its general signature uses sorted IDs plus filenames, sizes and millisecond mtimes, compressed to Java String.hashCode and input length. Separate audited exclusions contribute additional keys. The generic signature is not a content digest: a same-size/same-mtime replacement can evade its change detector, and a 32-bit hash is not a collision-resistant identity. The manually maintained schema must also track contract changes. This is a correctness boundary, not proof of an observed bad launch. Pinned gate source
Better design: retain a content-keyed per-artifact raw GL-reference inventory, then reevaluate it against the current contract digest, active configuration, loaded mod IDs/platform and exact inactive-audit evidence. This avoids decompressing every class when only translation support changes. Preserve full owner/name/descriptor and nested provenance. Cache negative findings too, but never turn an unreadable artifact or unknown audit state into a native pass.
Strong hashing still reads bytes. Compare hash cost against ZIP inflation/ASM parsing and reuse an already verified ingestion digest where identity is reliable. Do not pretend filename/mtime alone is cryptographic assurance. Bound nested sizes/depth and reject malformed cache files without allocating unbounded memory.
ModernFix already has a dedicated reload executor with the context class loader preserved, a resource-path cache, faster access-transformer lookup, model optimizations and a faster texture stitcher. First inventory the exact installed version and effective options, then profile which paths remain costly. ReloadExecutor, PackResourcesCacheEngine, FastAccessTransformerList
The inspected stitcher deliberately falls back to vanilla for atlases with fewer than 100 entries because consumers such as JEI can depend on alignment. Keep that compatibility escape rather than forcing every atlas through a new packer. Stitcher source
Dynamic resources defers block/item model work and can improve loading/memory, but its author identifies compatibility risks. Qualify Create, connected textures, custom model loaders, resource packs, JEI, reloads and first-use hitches before enabling it in the full pack. Keep problematic resource families eager without discarding their features. Dynamic Resources FAQ
The pinned Hari ModernFix audit recognizes exact 5.27.83/5.27.85 artifacts and an inactive asynchronous GL loading-screen path. Updating ModernFix can invalidate that exact audit. Reaudit the actual artifact and effective option; do not blanket-whitelist every version or enable an auxiliary OpenGL loading context in native-only mode.
Use ModernFix's GA settings as the stable starting point; Beta is an experimental qualification lane, not an automatic full-pack upgrade. ModernFix also contains dynamic DFU handling, so stacking an old LazyDFU clone is not a reasoned first move. Stability levels, DFU source
Prefer contributing loader/resource fixes upstream with minimal reproductions and timings, and maintaining only Hari-specific integration locally. Respect the upstream license and attribution when reusing code. No untested PR was submitted in this research pass.
A generation-qualified resource index should answer repeated namespace/path enumeration once, while preserving resource-pack order and override/filter semantics. Changed packs invalidate relevant entries. Do not persist user/resource object graphs blindly; custom loaders may generate data dynamically or consult configuration.
Split loading into independent preparation and ordered publication: immutable input -> read/decode/parse -> dependency resolution -> appropriate-thread apply/upload. Preserve reload barriers and cancellation. Never publish a half-built atlas or replace resources still referenced by an old generation.
ModernFix documents a concrete hazard: registering reload listeners from parallel setup can race the reload itself. Use the loader's listener-registration events and preserve reload ordering; adding a pool does not fix a listener added too late. Reload-listener guidance
DashLoader is useful precedent for persistent asset caching and uncachable-asset fallbacks. Its own documentation warns of first-build cost and compatibility limits. Adopt the architectural lesson, not its branding as a promise or a presumed Forge port. Cache formats need explicit adapters for custom models, dependencies, texture metadata, animation and resource-generation identity. DashLoader
Hari already persists a Vulkan pipeline cache. Preserve it. A driver pipeline cache does not automatically remove GLSL include resolution, translation or shaderc SPIR-V compilation. In the inspected SPIRVUtils.compileShader, the call proceeds to shaderc; instrument caller-level duplicate requests before adding a new cache.
Cache immutable SPIR-V by transformed source and all includes, stage/entry point, defines, compiler version, target environment and options. Coalesce identical in-flight requests. Own native result buffers explicitly, snapshot include search paths and resource generations, and release canceled/stale outputs. Compiler parallelism runs on the CPU, not as GPU shader execution. Shared Java include lists/profiling counters and callback state also require review even when a native compiler API permits concurrency. Hari SPIRVUtils, shaderc contract
For native pipelines, prewarm only a measured hot set and build remaining independent pipelines on bounded workers with correct publication/lifetime. No dummy shaders or missing draws. Vulkan cache concurrency depends on creation flags and the API contract; externally synchronized mode needs application synchronization. A future pipeline-binary path is feature/driver gated, not a universal replacement. Pipeline cache, pipeline specification, pipeline-binary sample
See GPU-AND-TEXTURE-STARTUP.md for the detailed decision matrix and newly identified mipmap CPU candidate.
Highest-value GPU research: batch texture upload, correctly synchronized transfer/compute overlap, and exact texture processing for sufficiently large assets that remain GPU-resident. Compare against warm decoded/mip caches and optimized CPU workers. PNG decoding and ZIP inflation are different steps; GPU decompression does not parse JSON, initialize mods or resolve model graphs.
DirectStorage/nvCOMP/GDeflate are real technologies, but are not a switch that accelerates existing Forge JAR loading. Integration, format compatibility, device support, transfer cost and CPU consumers determine value. Keep a portable lossless CPU path. Do not introduce lossy compression, lower mip counts or reduced texture resolution to manufacture startup gains.
- Stay on the pack's qualified Java runtime first. Verify default CDS is enabled; experimentally evaluate dynamic AppCDS for eligible classes. Java 17 CDS supports custom loaders, but this does not guarantee reuse of Forge-transformed classes. Inspect actual hit/miss logs. Key archives to the JDK/build environment and allow safe fallback rather than requiring a valid archive. Java 17 CDS
- Newer Leyden/AOT work is an upgrade research lane, not a Java 17 flag. A newer JDK can break ASM/Mixin/native assumptions; full-pack qualification is required. OpenJDK Leyden
- Do not use reduced JIT optimization to win startup while sacrificing sustained FPS. Compare heap/GC choices with both startup and gameplay; overlarge heaps and eager page-touching can increase memory pressure/startup cost.
- Keep active mod/cache files on suitable local storage with free space. Distinguish first/cold IO from warm OS cache. Do not disable antivirus, security scanning, signature verification, updates or the pagefile as an optimization shortcut.
- Full-process checkpoint/restore is not the first Windows solution: CRaC's documented real checkpoint backend is Linux-oriented, and GPU/audio/network/file resources require coordination. A serialized asset cache is more bounded than a frozen game process containing device handles and credentials. CRaC runtimes
ModernFix's inspected handshake patch removes a one-login-payload-per-tick pacing bottleneck while retaining synchronization and completion checks. This can address an otherwise low-CPU world-join wait; it does not shorten pre-menu class scanning. Verify whether the installed build already contains it. HandshakeHandlerMixin
Ksyxis/Fastload-style world-load shortcuts are not automatic solutions to the Forge launch bar. Changes to spawn-chunk semantics or skipping readiness conditions violate the no-loss goal unless individually approved and qualified. Preserve world migration and mod datapack/recipe callbacks. Ksyxis scope, Fastload scope
| Priority | Experiment | Why first | Promotion evidence |
|---|---|---|---|
| P0 | Phase timers and local startup profile | Identifies the real serial/IO/CPU bottleneck | Reproducible critical-path trace, minimal observer overhead |
| P1 | Reconcile existing ModernFix/Hari caches and effective options | Avoids duplicating mature work or breaking exact artifact audits | Hash-pinned full pack, working reloads and unchanged features |
| P1 | Per-artifact structural scan/GL-reference cache | Removes repeated work across unchanged launches | Correct same-size/mtime replacement, nested change and contract invalidation |
| P1 | Mipmap average fusion and row-major traversal | Small visible source-level allocation/locality opportunity | Actual Java/native byte equivalence and measured stage time |
| P2 | Bounded parallel pure parsing | Addresses the inspected single-worker scan boundary | Stable callback order, all providers correct, better cold and warm wall time |
| P2 | SPIR-V result cache and duplicate-job coalescing | Targets repeated compiler work separately from pipeline cache | Includes/options/reload invalidation and full image validation |
| P2 | Resource/model preparation with qualified dynamic paths | Potentially substantial with many assets | No missing custom models, first-use hitches or memory regressions |
| P3 | Batched transfers and exact GPU texture processing | Exploits data that remains on the GPU | CPU/GPU parity, end-to-end gain including startup/device/transfer costs |
| P3 | Eligible AppCDS and measured JVM tuning | May reduce class metadata/setup cost | Actual archive hits; no sustained FPS/frame-time regression |
| Research | Transform output cache, GPU ZIP decode, whole-process restore | High integration/semantic risk | Determinism/device/runtime proof before pack deployment |
Use the full intended pack, including Create and custom patches. Match hardware/power mode/background activity, resolution, mod hashes, JVM arguments and resource settings. Keep runs with a genuinely cold artifact cache separate from warm-cache launches and from first launch after a changed mod. Alternate baseline/candidate order and report distributions, not one best time.
Test unchanged restart; change one mod; change a nested dependency; reorder resource packs; change shader includes/options; corrupt/truncate a cache; interrupt cache writing; run two game processes; perform F3+T; enter worlds/dimensions; open JEI/creative search; exercise Create and custom effects. Caches must remain bounded and disposable; originals remain authoritative.
Amdahl's law is a useful sanity check: if a phase occupies 20% of startup, even eliminating it entirely caps the total speedup at 1.25x. That is an illustration, not a measured phase share. Choose work by measured saved seconds on the critical path and memory/compatibility risk, not by how advanced the technology sounds.
Completion threshold: lower median and tail launch-to-usable times, no shifted first-use stalls, no lost features, bounded memory/disk, and unchanged or improved gameplay frame-time tails. Current status: researched and specified; not implemented or full-pack benchmarked in this pass.
October 15, 2026. Companion to STARTUP-ACCELERATION-ROADMAP.md. Recommendations below are engineering hypotheses unless explicitly marked as measured observations. No GPU/game execution occurred.
I read the ZIP central directories of the 28 previously hash-verified reference artifacts. They contain 64,570 top-level non-directory entries. This sample includes multiple versions of some mods and is NOT the installed 327-mod pack. Nested JAR contents were not expanded in this measurement. It says nothing about which entries are actually needed during startup.
| Type | Entries | Total encoded payload after outer ZIP inflation | Median payload | Under 64 KiB |
|---|---|---|---|---|
| Java class | 21,846 | 99,408,440 bytes | 2,791.5 bytes | 21,811 |
| JSON | 29,298 | 110,825,877 bytes | 301 bytes | 28,976 |
| PNG | 8,159 | 77,095,569 bytes | 543 bytes | 8,074 |
| Ogg | 4,110 | 150,711,800 bytes | 19,509 bytes | 3,773 |
| Nested JAR | 44 | 70,253,843 bytes | 195,768 bytes | 8 |
PNG numbers are compressed PNG file payload sizes, NOT decoded RGBA image memory. Likewise, Ogg payload size is not decoded PCM size. All listed outer entries use ZIP DEFLATE (method 8). Full metadata and the original read-only inspection script are included as jar-entry-shapes.json and inspect_jar_entry_shapes.py.
Implication: per-entry GPU submissions would target many tiny tasks. Batch size, JNI/native setup, transfers and the destination of the decoded bytes matter much more than a vendor's large-buffer throughput number. This observation motivates a benchmark; it does not prove GPU processing is always slower.
| Work | CPU / caching first | GPU fit | Compatibility constraints |
|---|---|---|---|
| JAR directory/metadata discovery | Persistent per-artifact index; bounded IO | Poor first target | Nested provider, signature and error semantics |
| Class annotation parsing | Cached immutable scan data; independent CPU workers | Low priority; Java/ASM consumers remain CPU-side | Language providers and exact result shapes |
| Java class initialization / registries | Remove duplicate work; existing ordered lifecycle | Not directly GPU executable | Arbitrary Java/native side effects |
| JSON/model dependency resolution | Parse/dependency cache and CPU preparation | Low for object-graph construction | Custom loaders, variants, configuration and resource order |
| ZIP DEFLATE | Measure JVM inflation and optimized CPU alternatives | Potential batched research if inflation dominates | Exact codec/container/CRC and byte parity; CPU readback often required |
| PNG decode / texture preprocessing | Bounded decode jobs; lossless decoded/mip cache | Good only after full decode/filter pipeline qualification | PNG features, alpha/gamma, CPU pixel consumers |
| Texture mip computation | First improve current CPU path | Plausible for larger textures and batches | Exact current filter semantics, image ownership and barriers |
| Texture upload | Batch, reuse staging, avoid needless waits | Strong native Vulkan integration target | Queue ownership, lifetime, full readiness before use |
| GLSL/SPIR-V compilation | Cache and coalesce CPU compiler requests | Shader compiler is host work | Include state, options, compiler version |
| Vulkan pipeline creation | Persist driver cache; bounded host workers | GPU-specific output, largely host/driver creation work | Feature flags, driver compatibility and object lifetime |
Hari's published MipmapGeneratorM is declared in the active Vulkan mixin configuration. Its calculateAverage first allocates an int array sized to the whole image, collects nonzero-alpha pixels, then sums their RGB channels. Several loops use x as the outer loop and y as the inner loop, although pixel storage is row-major (x + y * width).
A small first optimization is to fuse collection and RGB accumulation, removing the pixel-sized temporary array, and traverse rows contiguously. The same locality change can be considered for independent per-pixel preprocessing and each mip level, while retaining all dependencies between levels. Do not change the alpha selection threshold, integer division/rounding, existing overflow behavior without a separate correctness decision, or gamma formulas as part of a supposedly equivalent speed patch.
The original host model in probe_mipmap_average_equivalence.py checked 256 deterministic cases totaling 1,307,181 pixels, including all-transparent, all-opaque and mixed-alpha images. The old collection model and fused summation model agreed in every case. Dimensions were 1–129 and sums did not overflow. This is a Python model of average computation only: not the actual Java/native mixin, full mip chain, GPU implementation or a timing benchmark.
Before promotion: run the real Java/native implementation on actual resource-pack textures; compare every output byte at every mip, measure allocation and stage time, then validate transparent edges, animated sprites, custom mip chains, reloads and first-use rendering. For large textures, separately audit arithmetic overflow and allocation limits without silently redefining the baseline.
The inspected Hari mipmap path includes transparent-pixel RGB preprocessing and gamma-based blending. A generic linear vkCmdBlitImage mip chain is not a substitute for that full algorithm. The Vulkan sample itself distinguishes simple blits from custom filtering shaders. GPU float precision/rounding and alpha behavior can differ from Java even when images look close. Khronos mipmap sample
A possible native compute path should:
- Preserve explicit supplied mip levels and all animation/frame metadata.
- Dispatch enough independent texels per batch to amortize command overhead.
- Reproduce the accepted filtering/preprocessing semantics, including transparent edges and atlas boundaries.
- Track texture generation, subresource layout and transfer/compute/graphics dependencies.
- Publish only completed resources and retain old resources until all readers finish.
- Keep the CPU path for unsupported formats, small inputs and mods that require immediate CPU pixel data.
A GPU path that must synchronously download every mip back into NativeImage may lose its benefit. Preserve the public CPU-image contract; do not make getPixel, resource hooks or custom loaders return stale data to avoid readback. Start with explicitly qualified GPU-only consumers or a cache that satisfies both CPU and GPU needs.
A repeat-launch accelerator can persist exact decoded pixels/mips or immutable intermediate data keyed by source bytes, resource-pack ordering, metadata, decode/filter version, relevant options and custom adapter identity. Upload that data in larger contiguous batches instead of repeating expensive decode/filter stages.
Do not extract every JAR into thousands of permanent files: that can increase file-open/scan overhead and disk usage. Consider a bounded packed cache with an index and chunk checksums, atomic publication and eviction. Decoded textures are often far larger than PNG originals, so cache only measured expensive/hot assets and impose a byte cap. Cache construction cost must be reported separately from later launches; the first launch after a change must still be tolerable.
GPU-friendly compression such as GDeflate could be an optional format for this derived cache. It is not the same bitstream as an ordinary ZIP DEFLATE entry. Keep original JARs untouched; do not repackage signed mods or claim compressed bytes are interchangeable.
Microsoft's DirectStorage examples cover high-throughput asset reads and GPU/CPU decompression. Integrating the D3D12-oriented GPU path with a Vulkan renderer requires a real interop/data-lifetime design; merely installing a runtime does not accelerate Java ZipFile. Official DirectStorage repository
NVIDIA nvCOMP supports several codecs and device-dependent acceleration. Its large-batch/decompression-engine figures do not include this pack's Java object construction, all transfers or shader preparation. CUDA support is not a cross-vendor Vulkan contract. NVIDIA also documents a Vulkan GDeflate path via device-specific support and custom compute alternatives; this is a real research lead for prepared GPU-resident assets, not a universal requirement. nvCOMP, Vulkan integration example
For a CPU-consumed payload, compare total cost: reading + batch construction + compressed host-to-device copy + GPU decode + decompressed device-to-host copy + synchronization + Java wrapping/parsing. Compare against the same input using the existing JVM and an optimized CPU decoder. If bytes stay on-device, the costly return trip can disappear, changing the answer.
libdeflate is an established whole-buffer DEFLATE/zlib/gzip implementation worth comparing only if inflation is a measured bottleneck. It is not a zlib-streaming drop-in. A JNI integration must preserve output bounds, CRC/size/error semantics, ZIP64/container handling and signed-JAR verification. Do not change Forge's archive reader globally for an unmeasured microbenchmark win. libdeflate
AMD's Brotli-G is another GPU asset-compression reference, but a different encoded format again means a derived-cache/toolchain experiment rather than direct acceleration of existing mod archives. AMD GPUOpen
Use a bounded staging arena, group compatible upload regions, record commands through properly owned command pools and submit batches. If the hardware exposes useful transfer/compute overlap, evaluate it; queue-family ownership and synchronization can erase gains on some systems. Keep retirement tied to completion, not Java object lifetime. Avoid per-texture queue-idle waits, but never remove a wait without replacing its ordering/lifetime guarantee. Vulkan threading guidance
Instrument bytes decoded/uploaded, number of submissions/waits, GPU stage time, peak staging/native/VRAM usage and end-to-end time. Test under concurrent Forge CPU work and with the loading screen rendering; a synthetic idle-GPU result is insufficient.
No reduced texture resolution, lossy transcoding, skipped mip levels, discarded animations, dummy shaders, dropped model callbacks or early 'ready' screens. No automatic background profile uploads. No platform-specific acceleration without a compatible fallback. No claim of instant startup or a percentage gain until the full pack is measured.
Prepared 2026-10-15. No launches are authorized by this document itself. This is the handoff for the existing engineer when the user resumes the relevant testing work.
- Exact Minecraft, Forge, Java vendor/build, launcher, Hari and all mod/nested-mod hashes.
- Preserve custom patched artifacts; record exact effective ModernFix configuration and audit pins.
- CPU/GPU/driver, physical/logical cores, RAM, storage location/free space, power mode and background workload.
- Resource-pack ordering, configs, shader options, resolution and initial scene.
- Cache inventories, total disk size, schema version and valid/warm status; don't clear caches silently.
Measure process start -> first window -> main-menu input -> selected world join -> controllable rendered world. Then inventory/JEI first search, Create scene, first custom scope/effect, dimension transition, resource reload and return to menu. Report first-use stalls separately from steady-state p50/p95/p99 frame times.
- Existing qualified pack, caches warm.
- Same pack, derived caches absent, OS cache state stated honestly.
- Repeat launch with unchanged pack.
- Change one mod, then repeat.
- Change nested dependency only.
- Change resource-pack order/config/shader include.
- Corrupt or truncate one disposable cache entry.
- Interrupt a cache write, then relaunch.
- Concurrent instances sharing the cache location.
- Full original-feature regression scene and gameplay tails.
Alternate baseline/candidate launch order; retain individual run records. First gather repeatability/noise, then choose enough repetitions to separate an effect from noise. Report median and range/tails, not only the best run. Cold-cache classification must distinguish OS page cache from application caches. Do not delete unrelated files or disable system security to manufacture a cold run.
- Inspect existing cache hits/misses and repeated source compilation.
- Remove mip-average temporary allocation and improve traversal locality, with byte tests first.
- Add pure per-artifact scan results with deterministic invalidation/fallback.
- Add bounded parsing workers, preserving provider callbacks and class-loader context.
- Coalesce shader compile jobs and introduce versioned SPIR-V cache.
- Batch native uploads while preserving completion and frame readiness.
- Only then experiment with selective dynamic models or GPU texture processing.
For each change record: affected stage, wall seconds saved, CPU time/allocations, native/RAM/VRAM peak, cache bytes, warnings/errors and feature results. State whether the improvement is cold launch, warm launch, world join or first-use. Aggregate startup numbers must not hide a regression in a separate stage.
- Same visible models/textures/mips/animations and shader outputs.
- Same registry/dependency results and game callbacks; no silent missing metadata.
- Same original saved-world migration behavior.
- Original audio, UI, connected textures, Create and patched-mod behavior present.
- Correct fallback for unsupported devices and changed/corrupt caches.
- No renderer conflict bypass or false native acceptance.
- No new permanent background scans/uploads or unbounded cache/recording retention.
Forge: bounded structural scan API with deterministic merge and callback boundary, or a stable scan serialization contract. ModernFix: targeted resource/loader improvements with minimal repro and source-version-specific test cases; avoid duplicate broad mixins. Hari: native gate artifact inventory, shader-result caching, texture pipeline/locality and queue scheduling. Keep device-specific GPU experiments optional until cross-device acceptance.
No PR should claim measured pack gains until those measurements exist. Keep upstream licenses and attribution intact.