Strict Zero-Allocation

In high-frequency robotics (250Hz+), the #1 cause of sudden, non-deterministic jitter is the Java Garbage Collector (GC). Every time you use the new keyword inside a loop, you are creating a tiny bit of “trash” that the CPU eventually has to stop everything and clean up.

Caution

The 20ms Deadline

If the GC triggers during a critical autonomous spline, your 20ms control loop might stretch to 40ms. This causes the robot’s pose estimator to miss reality, leading to a missed shot or a collision.

1. The Ephemeral Proxy Pattern

MARSLib enforces zero-allocation using Ephemeral Proxies. Instead of creating new Translation2d objects every loop for math, we reuse static, pre-allocated memory buffers.

Try clicking ALLOCATE OBJECT in the simulator below to see how heavy object creation “spikes” the loop time and forces the GC to halt the robot!

2. MARSLib Constraints

The marslib-audit skill strictly forbids the following patterns in “Hot Paths” (periodic loops):

• No new: Use Inputs structs or static caches.
• No Lambdas: Use pre-defined Runnable or Consumer fields.
• No String Building: Use the Logger.recordOutput raw numeric overloads.

---

📖 Further Reading & External Resources

• AdvantageKit: Performance & Benchmarking - Technical specifications for zero-allocation logging.
• Java Garbage Collection Tuning - Understanding the impact of object allocation on real-time systems.