Adaptive Optimization — New Preview

This preview represents one of the biggest changes Adaptive Optimization has received since the project began.

Until now, the mod already contained many optimization, adaptation, learning, and control systems, but a large part of its architecture still relied on measurements that were too general, weak evaluation methods, and legacy systems that made it difficult to know with confidence whether an optimization was actually improving the game.

That starts changing with this preview.

Adaptive Optimization now has a much stronger foundation for observing Minecraft, identifying where performance problems are coming from, and measuring whether the game is actually improving.

Adaptive Optimization now actually works

This is the first preview where the new architecture is starting to produce real, useful results in-game.

During testing, Adaptive Optimization was able to improve Minecraft's performance while continuously observing real workloads without breaking normal gameplay.

The mod is no longer being developed around the idea of simply applying predefined tweaks and assuming that they help.

The new goal is:

Observe → Identify → Diagnose → Experiment → Measure → Roll Back → Learn → Improve

And a large part of the foundation required for that system is now implemented.

---

Much better workload detection

Adaptive Optimization can now distinguish much more clearly where workload is coming from.

It can identify and separate things such as:

• Vanilla Minecraft
• Individual mods
• Classes and methods
• Client and server workloads
• Entities
• Pathfinding
• Scheduled ticking
• Chunks
• Networking
• I/O
• Rendering
• Commands
• Filesystem activity
• Lock contention
• CPU pressure
• Memory pressure
• Garbage collection
• Other unknown workloads

Targets now have stable identities instead of being treated as nothing more than optimization action names.

This gives Adaptive Optimization a much better understanding of what it is actually observing.

---

Vanilla and modded workload attribution

AO can now determine whether observed work belongs to:

• Vanilla Minecraft
• A specific mod
• A subsystem
• A semantic workload group
• Or UNKNOWN when there is not enough evidence

This last part is especially important.

Adaptive Optimization is no longer required to invent a diagnosis just because something is expensive.

If the evidence is not strong enough, the mod can keep observing instead of pretending that it knows the answer.

---

Major profiler improvements

The profiling system has been heavily upgraded.

Adaptive Optimization can now observe workloads across multiple time windows and determine whether a workload is:

• Emerging
• Persistent
• Disappearing
• Sporadic

Stack attribution was also improved so workloads are not fragmented into dozens of unrelated method samples when they are actually part of the same underlying operation.

This has already helped AO identify real workloads much more reliably during stress tests.

---

More reliable sampling

The sampler can now change its observation rate depending on what is happening.

It can operate at lower cost during normal gameplay and increase sampling when more information is needed.

It also tracks observation quality, including:

• Dropped samples
• Queue pressure
• Missing thread information
• Identity degradation
• Sampling density
• Sampling mode changes

This prevents an important false-positive case:

AO cannot claim that performance improved simply because its own profiler stopped seeing the workload.

---

Real server tick measurement

One of the most important additions in this preview is proper server tick measurement.

Adaptive Optimization now measures real server tick duration using Forge's server tick boundaries while also reading Minecraft's own internal tick timer as an independent reference.

Two separate measurements are retained:

• Forge Server Tick Event Span
• Minecraft Recorded Server Tick Duration

They are intentionally not merged into a fake single metric.

This allows AO to detect cases where Minecraft's core tick improves while Forge/mod-related work around it becomes worse, or vice versa.

During runtime testing:

• Tick samples remained continuous
• No normal-operation anomalies were detected
• No server-thread violations occurred
• Active measurement windows had no sample loss
• Both measurements reacted correctly when server workload increased
• Monitoring overhead remained extremely small

Adaptive Optimization can now measure actual server-side performance far more reliably than before.

---

Experimental measurement windows

The new causal evaluation system has also started being implemented.

Adaptive Optimization now supports independent measurement phases:

• PRE
• EXPERIMENT
• RECOVERY

This means future optimization experiments can measure the game before an optimization is applied, while it is active, and again after it is rolled back.

The old architecture could sometimes evaluate accumulated statistics or capture baselines after an action had already affected the game.

The new system is being designed specifically to eliminate that problem.

---

Workload comparability

AO can now determine whether two measurement windows are actually comparable.

It can detect situations such as:

• The target disappearing
• Large workload changes
• World changes
• Dimension changes
• Reloads
• Lifecycle or pause transitions
• CPU shifts
• Garbage collection activity
• Heap pressure changes
• Lock contention
• Network bursts
• Sampling degradation
• Lost samples
• Changes in player/workload context
• Required metrics being unavailable

If the experiment cannot be evaluated reliably, AO does not need to force a positive or negative answer.

It can return:

INCONCLUSIVE

and refuse to learn from that experiment.

---

New causal result system

The foundation for proper optimization experiments is now implemented.

Future experiments can independently evaluate:

Performance

• IMPROVED
• REGRESSED
• NO_EFFECT
• INCONCLUSIVE

Safety

• SAFE
• UNSAFE
• UNKNOWN

Semantics

• PASS
• FAIL
• NOT_VERIFIED

The final experiment result can then become:

• ACCEPT
• REJECT
• INCONCLUSIVE
• ABORTED

Adaptive Optimization will eventually only learn from results that meet the required evidence, safety, semantic, and comparability conditions.

A contaminated experiment, restart, missing metric, unstable workload, or incomplete test should no longer become fake learning data.

---

Improved persistence

Several legacy persistence problems have also been corrected.

Improvements include:

• More reliable state round-tripping
• Consistent periodic and clean-shutdown saves
• Compatibility fixes between previously mismatched saved fields
• Proper persistent timestamps instead of using JVM-local monotonic time across restarts
• Safer restoration of active bindings
• Better separation between persistent knowledge and session-only observations

This makes the learning foundation much safer for future previews.

---

What is still missing?

The observation and measurement systems are now significantly stronger, but Adaptive Optimization is not finished yet.

The next major step is connecting everything together into a real experimental optimization coordinator.

The future system will work approximately like this:

Observe a problem
↓
Identify the target and workload
↓
Generate/select an optimization candidate
↓
Measure PRE baseline
↓
Apply the optimization
↓
Stabilize
↓
Measure EXPERIMENT
↓
Roll back
↓
Measure RECOVERY
↓
Check safety and behavior
↓
Accept, reject, abort, or mark inconclusive
↓
Learn from trustworthy results

That is the part that will turn Adaptive Optimization from a powerful optimizer with adaptive systems into a genuinely autonomous optimization platform.

---

Plan for the next previews

Next previews — Experimental Coordinator

The next stage will introduce the central experiment coordinator.

It will control the full lifecycle of optimization experiments and ensure that only one controlled intervention owns the relevant optimization state at a time.

It will also introduce a crash-safe experiment journal so unfinished experiments cannot silently become permanent changes after restarting Minecraft.

---

Later previews — Real autonomous experiments

Once the coordinator is stable, AO will begin testing real optimization candidates using the new PRE / EXPERIMENT / RECOVERY system.

The first candidates will be intentionally small and reversible.

The goal is to prove that AO can:

• Apply an optimization
• Measure the real result
• Roll it back safely
• Detect regressions
• Reject placebo optimizations
• Keep genuinely useful improvements

---

Later previews — Learning integration

After causal experimentation is proven reliable, the existing learning systems will be connected to the new experiment results.

AO will begin remembering:

• Which strategies worked
• Which failed
• Which workloads they worked on
• Which mods were involved
• Which environments were compatible
• Which candidates should not be attempted again

The learning system will gradually become less dependent on fixed rules and more capable of selecting optimization strategies from previous experience.

---

Later previews — Autonomous candidate generation

The long-term goal is for Adaptive Optimization to move beyond a closed list of predefined actions.

AO should eventually be able to diagnose new workloads and construct optimization candidates using safe primitives such as:

• Caching
• Memoization
• Deduplication
• Batching
• Coalescing
• Reuse
• Deferring work
• Scheduling
• Invalidation
• Safe throttling
• Interception
• Fast paths
• Safe rewrites

Candidates will still need to pass experimentation, safety checks, rollback validation, and semantic verification before being accepted.

---

Working together with the rest of the optimization ecosystem

Adaptive Optimization is also being designed to work alongside specialized optimization mods rather than making them obsolete.

Projects such as:

• Sync Fix
• Chunks Optimization
• Logs Fixer
• Render optimization systems
• Mods Fixer

will continue to deeply optimize their own areas.

Adaptive Optimization will be able to add additional adaptive and cross-system optimizations when they provide measurable value, while avoiding blindly duplicating the exact same optimization mechanism.

The goal is not to artificially limit AO.

The goal is for all optimization systems to work together and achieve better performance than any one of them could achieve alone.

---

Current status

This preview is an important turning point.

Adaptive Optimization already appears to provide meaningful performance improvements in real Minecraft testing, while the architecture underneath it is being replaced with systems capable of proving whether those improvements are actually real.

The mod still has a lot of work ahead of it, but the foundation is now significantly stronger.

Adaptive Optimization is no longer just learning how to optimize Minecraft.

It is starting to learn how to prove that its optimizations actually work.