What's new since the Initial Preview

The first Fast Loading preview established the foundation:

environment identity
↓
loading telemetry
↓
persistent loading knowledge
↓
bounded caching
↓
adaptive profiles
↓
experimentation
↓
promotion / rollback

Since then, Fast Loading has expanded far beyond that initial foundation.

Fast Loading is now approaching completion.

Most of the major architectural systems required for the finished mod now exist.

Development is increasingly shifting away from:

"build the missing architecture"

toward:

"validate, connect, optimize and close the remaining gaps."

This does not mean Fast Loading is completely finished yet.

But it does mean the project is entering its final development stage.

Forge metadata can now be reused safely

Fast Loading now has a productive content-addressed cache for Forge mods.toml metadata.

Instead of trusting:

• filenames;

• paths;

• timestamps;

• previous modpack identity;

Fast Loading hashes the exact current metadata content.

If the current mods.toml bytes are identical to a previously parsed version, Fast Loading can reuse the parsed result.

If they differ:

the cache is rejected and Forge parses the current data normally.

This also means identical metadata can safely be reused across different JARs or modpacks when the content itself is exactly the same.

Forge class and annotation scanning can now be cached

Fast Loading can also persist the pure class/annotation scanning results produced during Forge mod scanning.

This cache is tied to the exact content identity of the current JAR.

It does not freeze runtime-specific loader behavior.

Current language-loader visitors are still executed normally.

The cached part is limited to the scanning work that can be safely reconstructed from identical mod content.

If Fast Loading cannot represent a scan result safely:

it simply does not cache it.

JAR content identity no longer requires blindly hashing everything every launch

Fast Loading now has a structural JAR identity cache.

After an exact SHA-256 identity has already been established, later launches can validate the ZIP central directory first.

That structure includes information such as:

• entry names;

• CRC values;

• compressed sizes;

• uncompressed sizes;

• compression methods.

If the structure still matches, Fast Loading can reuse the previously established full content identity.

If anything suspicious changes or the ZIP structure cannot be safely interpreted:

Fast Loading falls back to hashing the complete current JAR again.

Paths remain hints.

They never become content authority.

Mod discovery now has an invalidation graph

Fast Loading has started moving away from:

one mod changed → invalidate everything

toward:

one mod changed → identify what may actually depend on it

A persistent dependency/invalidation graph can derive relationships from already validated Forge metadata.

This allows later caches to determine a smaller known impact set.

The graph itself does not modify Forge discovery.

It only helps Fast Loading understand which cached knowledge may no longer be safe.

Forge's background scanner can now use bounded adaptive parallelism

Fast Loading can now adapt the worker count used for Forge's background mod-content scanning.

It does not simply assume:

more threads = faster

The selected concurrency depends on the locally governed loading profile and available headroom.

Conservative or resource-limited environments can remain close to Forge's original single-thread behavior.

Machines that can benefit from additional parallelism can use more workers.

There is also crash/incomplete-launch protection.

If a previous adjusted scan did not reach normal runtime initialization, Fast Loading can force a conservative scan on the next launch.

It never skips the scan.

Main Forge mod loading can also use adaptive parallelism

Fast Loading can now influence the worker count used by Forge's main parallel mod-loading executor.

This remains bounded by Forge's own configured limit.

Fast Loading never uses more workers than Forge itself allows.

An incomplete adjusted launch also causes the next run to fall back toward Forge's original configuration.

The goal is not maximum thread count.

The goal is:

the amount of parallelism that actually loads the current environment faster.

Loading phases are now much more observable

Fast Loading can collect timing information from real Forge lifecycle boundaries.

This extends the original coarse startup measurement into a much more useful view of where loading time is actually being spent.

The critical path can be studied instead of treating startup as one giant number.

Importantly, Fast Loading does not invent dependencies simply because two events happened near each other.

Only boundaries that can currently be proven as blocking are included in the critical path.

Background work remains separate until a real dependency relationship can be demonstrated.

Fast Loading can learn the critical loading path

Previous session evidence can now be used to identify where the largest proven blocking cost exists.

That result can influence future prioritization.

But it remains only a priority hint.

It does not grant permission to:

• skip loading stages;

• reorder Forge semantics;

• bypass dependencies;

• defer required work.

The distinction remains:

knowing what is slow is not the same as having authority to change it.

Resource and texture-pack preparation is now persistent

Fast Loading has expanded beyond startup JARs.

It can now learn which portions of resource and texture-pack files are likely to be useful and perform bounded prefetching.

The implementation only warms file data into the operating system cache.

It does not:

• select resource packs;

• replace Minecraft resource data;

• change resource-pack ordering;

• substitute its own resource loader.

A bad prediction therefore means:

some unnecessary bytes were warmed

rather than:

Minecraft received incorrect resource data.

Shader-related preparation has begun

The same bounded preparation architecture can also recognize shader-pack related files.

Fast Loading can learn from previous resource/shader selections and prepare likely file ranges when appropriate.

It does not attempt to preserve unsafe GPU state across sessions.

It also does not change which shader pack the player selected.

This is preparation rather than ownership of shader behavior.

Resource and shader reloads can now be measured automatically

Fast Loading now observes real resource reload sessions.

It can retain:

• reload duration;

• completion state;

• resource-pack identity;

• shader selection identity;

• repeated reload patterns.

This creates a real evidence base for future reload optimizations instead of treating resource reload performance as part of an unexplained startup number.

World-entry preparation is now predictive

Fast Loading can learn from local worlds the player actually uses.

Before world entry, it can perform small bounded reads of likely useful local data.

World directory names remain prediction hints only.

They are never treated as authoritative pack or environment identity.

And Fast Loading never substitutes itself for Minecraft's actual world reader.

Minecraft remains the authority over world data.

Region hotsets can now be learned

Fast Loading can also retain bounded information about world regions that are frequently relevant.

For example, repeated player activity around certain region files can make those regions better future prefetch candidates.

A wrong prediction does not change chunk loading.

It only warms an unnecessary region header.

Fast Loading does not change:

• chunk ownership;

• save semantics;

• which regions Minecraft opens;

• world correctness.

World transitions are now measured

Fast Loading now records evidence around:

• entering worlds;

• leaving worlds;

• dimension transitions.

Repeated routes can become durable knowledge.

This makes it possible to learn that:

Overworld → Nether

may have different costs and preparation needs from:

Overworld → heavily modded dimension

without assuming every transition behaves the same way.

Server joining now has its own local preparation path

Fast Loading can now perform bounded client-side prefetch for known server joins.

This focuses only on work that exists locally.

It cannot eliminate network latency or accelerate a physically slow remote server.

But it can reduce avoidable preparation on the client side when reusable local information exists.

IO budgets can now adapt

World, resource and other speculative prefetch work now shares an adaptive IO-budget learner.

Fast Loading does not control Minecraft's own IO.

It controls:

how much speculative IO Fast Loading itself is allowed to create.

This matters because aggressive prefetching that helps an NVMe system may be harmful on:

• HDDs;

• saturated SATA drives;

• systems using heavy pagefile activity;

• low-resource machines.

Fast Loading can increasingly learn how much additional IO is actually useful.

Reconstructible caches now have their own storage budgets

Fast Loading also controls the size of data that can safely be reconstructed.

Derived cache data can be cleaned without touching authoritative evidence.

This begins solving a problem that becomes increasingly important over long-term use:

Fast Loading must not become slow because its own caches became enormous.

Automatic benchmark summaries now exist

Fast Loading can generate session-level benchmark information and compare it against historical evidence.

Instead of relying entirely on manual stopwatch testing, the system can increasingly reason from measurements covering its own runtime.

This is an important step toward eventually producing useful reports such as:

previous startup
vs
current startup

while also considering additional costs rather than blindly optimizing one number.

Fast Loading now has its own adaptive optimization intelligence

One of the largest changes since the first preview is the addition of:

Adaptive Loading Intelligence

Fast Loading no longer depends only on the original:

Conservative / Balanced / Aggressive

profiles.

It now has a specialized autonomous optimization architecture capable of representing generated:

• strategies;

• tools;

• mini-optimizers;

• executable plans.

This architecture is intentionally much smaller than Adaptive Optimization.

Fast Loading does not need AO's entire general-purpose governance system.

But it reuses many of the lessons learned while developing AO.

Generated strategies are content-addressed

Generated loading strategies now have durable semantic identities.

Fast Loading can distinguish the actual strategy from where or when it happened to be generated.

This allows equivalent optimization ideas to be recognized instead of endlessly creating duplicates.

Generated strategies also have lifecycle states such as:

• AVAILABLE;

• EXPERIMENTAL;

• TRUSTED;

• QUARANTINED;

• SUPERSEDED.

The strategy remains the lifecycle authority.

Generated optimization tools now exist

Fast Loading can construct reusable optimization tools from known Fast Loading capabilities.

These tools are not arbitrary code.

They are bounded descriptions of Fast Loading-owned optimization mechanisms.

A tool cannot independently decide that it should execute.

It remains connected to the strategy that created or uses it.

Mini-optimizers are now part of Fast Loading

Fast Loading can also maintain generated mini-optimizers specialized around individual loading scopes.

Current scopes include areas such as:

• discovery;

• resources;

• world entry;

• server joining;

• dimensions;

• world exit;

• Fast Loading's own overhead.

A mini-optimizer can specialize learning and candidate generation around its scope.

But:

mini-optimizers do not own lifecycle authority.

They cannot promote themselves or bypass the main strategy lifecycle.

Durable generated loading plans now exist

Fast Loading can materialize reusable generated execution plans.

A plan can compose allow-listed optimization tools into a concrete loading strategy.

However:

a plan deliberately has no lifecycle of its own.

Every time a plan is activated or used, it must still correspond to the exact locally governed strategy.

This prevents generated executable artifacts from accidentally creating a second optimization authority.

Experiments can now be scheduled autonomously

The adaptive system now includes a bounded experiment scheduler.

It can avoid several problems that would otherwise appear in autonomous optimization:

• candidates that never get tested;

• repeatedly testing an opportunity that never receives real workload exposure;

• immediate retry loops;

• promotion based on irrelevant sessions.

The scheduler can select appropriate AVAILABLE candidates when the required evidence exists.

Fast Loading now proves whether an experiment actually ran

This is a major improvement.

Previously it would be easy for an optimization system to say:

"profile X was active and startup improved."

But that does not prove that the optimization mechanism being tested actually participated.

Fast Loading now records execution witnesses.

These witnesses prove that the Fast Loading-owned primitive associated with the experiment was actually exercised.

Therefore:

no exposure means no causal promotion.

Runtime side is now part of authority

Fast Loading can now explicitly distinguish authority belonging to different runtime sides.

For example:

• CLIENT;

• DEDICATED_SERVER;

• integrated/cross-side situations where appropriate.

This prevents evidence produced on one side from silently becoming authority on another.

A CLIENT optimization cannot automatically become dedicated-server truth.

Scope-specific objectives are now used

Not every loading optimization should be judged by startup time.

Fast Loading now has scope-specific multidimensional objectives.

A resource optimization should be judged using evidence relevant to resources.

A world-entry optimization should receive actual world-entry exposure.

A server-join optimization should receive server-join evidence.

A dimension strategy should be judged against dimension-transition behavior.

This makes the adaptive system significantly more causal.

Fast Loading proactively explores loading coverage

The adaptive optimizer no longer has to wait only for the single worst loading bottleneck.

Fast Loading can maintain bounded coverage of its major optimization scopes.

This allows it to identify areas that:

• have little evidence;

• have never been optimized;

• may deserve a candidate;

• may have changed since previous observations.

The goal is not endless experimentation.

It is to prevent the optimizer from learning only about whichever bottleneck happened to be most obvious first.

Knowledge has HOT and COLD storage

Generated adaptive knowledge now has bounded active storage.

Frequently relevant information can remain in the HOT working set.

Older or retired information can move into crash-safe COLD storage.

Crucially:

authoritative evidence is not deleted just because it became cold.

The purpose is to reduce active runtime pressure while preserving history required for:

• provenance;

• recovery;

• learning;

• lifecycle reconstruction.

Lifecycle events now have a durable journal

Fast Loading's adaptive lifecycle now has an append-only, hash-chained journal.

This provides stronger durable evidence for events such as strategy transitions.

The system can therefore reconstruct what happened rather than trusting only whatever happens to be in memory during the current session.

Provenance now survives as its own durable chain

Generated knowledge also has a provenance ledger.

Fast Loading can retain information about how an artifact was influenced and where its knowledge originated.

But provenance itself remains separate from authority.

Knowing where an idea came from does not grant permission to execute it.

Cross-pack knowledge remains a prior

Fast Loading can reuse useful information learned elsewhere.

However, knowledge originating from another pack can only influence things such as:

• candidate generation;

• prioritization;

• exploration.

It cannot directly create local TRUSTED authority.

The receiving environment must still validate the strategy itself.

Semantic evolution and supersession are now implemented

Fast Loading can now recognize when multiple generated artifacts represent essentially the same optimization idea.

Instead of allowing equivalent strategies, tools and mini-optimizers to accumulate forever, it can select the best current representation.

Older equivalent representations can be retired and archived.

This gives Fast Loading a path from:

many primitive attempts

toward:

a smaller, more efficient active optimization vocabulary.

Working-set budgets are now environment-aware

The amount of adaptive state Fast Loading keeps active can depend on:

• environment;

• runtime side;

• current regime;

• available resources.

Budgets exist for generated:

• strategies;

• tools;

• mini-optimizers;

• plans;

• peer intents;

• maintenance work.

This helps the adaptive system scale toward very large modpacks without allowing its own intelligence layer to grow indefinitely.

Fast Loading can regulate its own maintenance cost

Fast Loading now has a self-lag governor.

Maintenance work such as:

• semantic reconciliation;

• working-set compaction;

• archival;

• peer maintenance

is explicitly budgeted.

If maintenance becomes too expensive, Fast Loading can defer reconstructible work.

But correctness-critical information such as lifecycle and provenance writes is not sacrificed.

The rule is:

performance pressure may delay maintenance, but it must not weaken correctness.

Runtime regimes can influence Fast Loading's own budgets

Fast Loading can increasingly distinguish different operating conditions.

An environment under heavy resource pressure should not necessarily use the same speculative loading behavior as an idle high-end system.

Regime information can therefore influence Fast Loading-owned budgets.

It does not alter Minecraft settings.

It changes only how aggressively Fast Loading spends its own resources.

Peer-to-peer coordination now exists

Fast Loading now includes an optional peer API for future Adaptive Mods.

This does not require Adaptive Optimization.

Other compatible optimizers can communicate concepts such as:

• optimization scope;

• ownership intent;

• heartbeats;

• released ownership;

• external evidence.

This allows future cooperation such as:

Fast Loading detects world entry bottleneck
↓
Chunks Optimization receives relevant evidence

or:

Fast Loading detects extreme log-related startup IO
↓
Logs Fixer can investigate its own specialization

But peer information never becomes local lifecycle authority by itself.

Generated physical capabilities now exist

Fast Loading has moved one layer deeper than generated strategies and plans.

It can now synthesize durable:

physical loading capabilities

from already governed generated plans.

These capabilities are not arbitrary generated Java code.

They are content-addressed compositions of allow-listed Fast Loading primitives.

They remain bound to:

• exact strategy;

• exact plan;

• runtime side;

• safety rules.

A physical capability also does not gain lifecycle authority simply because it exists.

Player intent and mod behavior now have a hard firewall

Generated optimization has an explicit semantic safety boundary.

Generated Fast Loading artifacts may modify:

Fast Loading-owned implementation cost

but they may not modify:

• player graphics settings;

• selected resource packs;

• shader choices;

• content fidelity;

• gameplay mechanics;

• functional behavior of Minecraft;

• functional behavior of other mods.

This is one of the main reasons Fast Loading can remain conservative despite becoming increasingly autonomous.

Classloading preparation has started without bypassing ModLauncher

Fast Loading now maintains a classloading hotset.

It can learn which classes are likely to be needed during startup and prefetch their original JAR bytes on later launches.

However, the current implementation deliberately does not:

• define classes itself;

• bypass ModLauncher;

• change class ordering;

• reuse transformed classes blindly.

This allows Fast Loading to optimize classloading preparation while preserving the normal transformation pipeline.

Transformation context now has an exact fingerprint

Fast Loading can now fingerprint the transformation-relevant environment.

This can include information derived from:

• Mixin configs;

• refmaps;

• coremods;

• access transformers;

• service declarations;

• manifests;

• exact pack identity;

• loader;

• JVM;

• runtime side.

If Fast Loading cannot completely inspect the transformation context, the fingerprint is marked incomplete.

Transformed bytecode reuse remains deliberately fail-closed

This is an important distinction.

Fast Loading now has much of the infrastructure required to determine whether transformation reuse could ever be safe.

But:

final transformed bytecode reuse remains blocked unless the complete transformer chain and side-effect equivalence can actually be proven.

A matching environment fingerprint alone is not considered sufficient.

Fast Loading can safely prepare:

• original class bytes;

• transformation metadata;

• deterministic inputs.

But it will not blindly reuse final transformed bytecode just because doing so might be faster.

This is an intentional safety boundary, not a missing cache bug.

Execution receipts now provide stronger causal evidence

Execution witnesses prove that an optimization received workload exposure.

Fast Loading now goes further with crash-durable execution receipts.

A receipt can bind actual execution to the exact:

• strategy;

• generated plan;

• physical capability;

• optimization scope;

• runtime side;

• installation;

• exact pack;

• transformation environment.

Receipts form a durable chain.

This gives later adaptive decisions much stronger evidence than:

"this strategy happened to be selected during that launch."

Fast Loading can now audit its complete runtime authority chain

One of the newest systems is the runtime closure audit.

Fast Loading can verify the complete chain:

strategy
↓
generated plan
↓
physical capability
↓
execution receipt

and check whether it remains:

• locally bound;

• side-safe;

• safety-firewall compliant;

• journal-valid;

• receipt-valid;

• crash-reconstructible.

The result can report states such as:

• READY

• DEGRADED

• BLOCKED

This audit is read-only.

It does not promote or execute anything.

Its purpose is to answer a much more important late-development question:

is the adaptive runtime actually connected correctly enough to trust the architecture itself?

Fast Loading is now much closer to the architecture originally planned

The Initial Preview described a long-term path that included:

startup
↓
mod discovery
↓
parsing
↓
classloading
↓
resources
↓
world entry
↓
servers
↓
dimensions
↓
saving / exit
↓
adaptive learning

A large portion of that architecture now exists in some form.

Fast Loading is no longer simply:

"a caching mod that might become adaptive later."

It now contains a specialized adaptive optimizer built specifically around loading.

Fast Loading is approaching completion

Fast Loading still has remaining work.

But the nature of that remaining work has changed significantly.

The major architecture is now mostly present.

The remaining development is increasingly concentrated around:

• final productive runtime integration;

• validating that every optimization actually exercises its intended primitive;

• real-world performance testing;

• finding remaining loading bottlenecks;

• fixing compatibility edge cases;

• validating recovery after crashes and interrupted launches;

• validating cache invalidation under mod/loader/JVM changes;

• validating low-end hardware behavior;

• validating extremely large modpacks;

• validating dedicated-server and integrated-server behavior;

• ensuring long-running caches and knowledge stores remain bounded;

• improving diagnostics and benchmark reporting;

• removing any remaining dead or redundant architecture;

• final semantic-preservation auditing.

And, where deeper reuse remains unsafe:

Fast Loading will continue falling back to normal Minecraft/Forge behavior instead of forcing an optimization.

What remains especially important

One of the final major areas is transformation reuse.

Fast Loading now understands much more about:

• classloading hotsets;

• transformation inputs;

• environment identity;

• invalidation;

• transformation fingerprints.

But final transformed-bytecode reuse requires an unusually strong correctness guarantee.

Fast Loading will not consider that feature complete simply because a cache can technically be implemented.

It must be demonstrated that reuse preserves the complete transformation result and relevant side effects.

If that cannot be demonstrated safely:

that optimization should remain blocked.

Fast Loading does not need every theoretically possible optimization to call the mod complete.

The focus now shifts to proof

The next phase is less about adding hundreds of new systems and more about proving that the existing ones work together.

That means measuring:

Fast Loading OFF / baseline
vs
Fast Loading ON

across:

• cold startup;

• warm startup;

• unchanged packs;

• changed mods;

• resource reloads;

• world entry;

• multiplayer joining;

• dimension transitions;

• world exit;

• low-end computers;

• large modpacks;

• extreme 1,000+ mod environments.

And measuring not only time, but also:

• CPU;

• RAM;

• GC;

• disk reads/writes;

• stability;

• crashes;

• Fast Loading's own overhead.

Adaptive Optimization is still continuing

Adaptive Optimization development has not stopped.

AO is still moving through its own final development and validation work.

But Fast Loading has progressed much faster than AO originally did because many difficult architectural lessons had already been solved there.

Fast Loading could reuse concepts such as:

• exact environment identity;

• provenance;

• lifecycle separation;

• rollback;

• multidimensional evidence;

• cross-pack priors;

• semantic preservation;

• working-set control;

• self-lag prevention;

• generated optimization artifacts;

• peer-to-peer coordination.

Instead of rediscovering those principles from zero, Fast Loading could implement smaller systems specialized specifically for loading.

What this update represents

The Initial Preview represented:

the beginning of Fast Loading.

This update represents something very different.

Fast Loading now has:

persistent caches
↓
incremental invalidation
↓
adaptive parallelism
↓
critical-path measurement
↓
resource/world/server prediction
↓
autonomous strategy generation
↓
tools and mini-optimizers
↓
durable plans
↓
experiments with real exposure proof
↓
semantic evolution
↓
working-set control
↓
self-lag protection
↓
peer coordination
↓
generated physical capabilities
↓
transformation safety boundaries
↓
causal execution receipts
↓
runtime closure auditing

The project has moved from:

"build a faster loader"

toward:

"build a loading optimizer that can learn how to make the current Minecraft environment load faster without taking authority away from Minecraft, Forge or other mods."

Fast Loading is almost finished

This may be one of the final major previews before Fast Loading moves toward its first complete version.

There can still be more preview releases if final testing exposes something that deserves another development cycle.

But the project is now close enough that the next major milestones are increasingly about:

validation, closure and release readiness

rather than building the core architecture.

The original question was:

how much waiting can we safely remove from heavily modded Minecraft?

Fast Loading now has most of the architecture required to seriously answer it.

Fast Loading is approaching its complete version.