Overview

Talon supports zero garbage steady state operation for applications that run with Event Sourcing as an HA policy. For low latency applications, avoiding creation of garbage or object allocation is desirable because that will result in GC pauses that cause latency spikes. In some applications, even a minor gc pause that results from promoting newly allocated objects to the tenured generation would violate SLAs. This section discusses the techniques application developers can apply to ensure that application code is garbage free, as well as some of the costs and alternatives application developers should consider before choosing to exploit them.
For the JVM to avoid any GC pauses, it isn't sufficient for the platform alone to produce no garbage; the application business logic must also not produce garbage. Talon provides tools to help applications achieve this. For an application to achieve zero garbage, it must:

• Preallocate state objects up front to avoid newly created state from causing object promotions. 
• Avoid autoboxing by using primitive types. 
• Avoid array creation.
• Avoid and replace Strings with XString. 
• Use zero garbage collections. 

Weighing the Alternatives

When considering the techniques oulined in the following sections, weigh the cost of achieving zero garbage in your application. An overarching goal of the X Platform and Talon is to allow application developers to write pure business logic without infrastructure concerns. While many of the techniques outlined below are simple to adopt, achieving absolute zero garbage can be costly in terms of development effort and maintenance. 

The X Platform offers a low latency edition that bundles Azul's Zing JVM. The Zing JVM offers an extremely low overhead concurrent garbage collector that can elimininate GC pauses without the application developer having to worry about pooling or preallocation of business objects. In addition, the Zing JVM has some other low latency treats, such as jit precompilation that can improve application wamup. We have worked closely with Azul to ensure that when combined with the zero overhead garbage profile of the X Platform, an application that is doing a moderate amount of allocation has median latencies on par with Oracle. 

Regardless of whether or not Zing is used, the following sections are still an important read for low latency developers. Some of the techniques employed will still result in a performance boost when using Zing, and are good practice anyway. 

Zero Garbage Techniques

The following sections describe the various techniques that can be used by application to interoperate with the platform in a zero garbage fashion. 

• XStrings — Java Strings pose challenges for ultra low latency applications looking to achieve zero garbage. Because java.lang.Strings are immutable they are not conducive to pooling and preallocation, and encoding and decoding of String can be cpu intensive. Consequently, Talon provides an alternate implementation, XString. 
• Embedded Entities — The X Platform's Application Data Modeling (ADM) framework allows modeling of messages that contain embedded entities. As an embedded part of the message to which the entity belongs, the entity is subject to the same pooling lifecycle and ownership constraints as its parent message: an application handler can not hold onto an embedded entity beyond the scope of a handler. For applications that are highly latency sensitive, and want to transfer the embedded entity as a whole into application stat
• Zero Garbage Array Accessors — The X Platform's Application Data Modeling (ADM) framework allows modeling of primitive, message and entity fields as arrays. For applications that are highly latency sensitive, it is useful to be able to work with such fields in a zero garbage fashion so that gc pauses can be avoided. Arrays are tricky to deal with from a garbage perspective because pooling of arrays presented directly to an application is quite difficult to achieve (imagine trying to pool arrays of every possible size needed b
• XBuf - Repeated Field Bulk Copies — This section discusses bulk copy support for repeated fields on Xbuf generated messages and entities. Bulk copies allow the encoded backing bytes for a repeated field to be copied as single direct memory copy without iteration at very low cost.
• Application Object Pooling — Platform generated messages and entities generated with Xbuf encoding are generated such that they support pooling out of the box. Latency sensitive applications can also use the platform's pooling facilities for user objects as well. This article shows how to make an application object poolable.
• Tuning Pools — To achieve zero garbage operation in steady state operation Talon pools objects to avoid allocations. Pools created by the platform start out with no objects preallocated, so it is important for performance sensitive applications to drive warm-up traffic at startup not only to allow for JIT optimization to kick in, but also to make sure pools are grown accordingly to reach an equilibrium state where enough instance of its objects have been allocated to satisfy the number of objects in use at a g
• Xbuf Configuration — Xbuf is the X Platform's zero garbage, optimized implementation of Google Protocol Buffer https://developers.google.com/protocol-buffers/docs/protos. It allows generating ADM objects (messages and entities) that act as a view into the backing protobuf encoded binary content. This section discusses some the additional advanced configuration knobs that are available XBuf generated types.