Skip to content

Garbage Reduction the Chronicle Way

One of the major benefits with using any Chronicle product is that we aim for almost Zero Garbage Collection (GC) there are several benefits to reducing Garbage:-

Pausing for Garbage Collection happens less often.

Creating fewer objects, reduces the overhead of allocating and clearing the object in the first place.

An indirect benefit comes from simplifying the object life cycle, which reduces the amount of time a GC takes, in addition this also reduces noise when trying to optimise an application which produces garbage.
Storing data off heap

Chronicle Queue, Chronicle Map and Market Data Distributor, support storing tera-bytes of data off-heap without adding significantly to the heap size or time to GC. Off heap memory can be as large as your disk space which can be several times main memory size and far beyond what is a practical heap size. This frees up your JVMs to use data more freely at a lower cost and simplify your designs.
Off heap memory is persisted and shared

Chronicle Queue, Chronicle Map and Market Data Distributor support concurrent writers and readers using persisted shared memory, this means there is only one copy in memory and no need for a broker.

Should all the processes die, no data is lost unless the Operating System also dies, Chronicle can protect a system against Operating System failure by utilising the replication features within Chronicle Queue and Chronicle Map. This is also true for our Chronicle FIX Engine which is underpinned by Chronicle Queue which it uses to persist its data

Recycling Objects and object pools
Our software is designed to recycle objects as much as possible, it uses object pools to minimise object creation. Our pools also include Strings and other immutable types. Many of our pools perform on average, faster than creating new objects. Pools can have a much smaller memory footprint and they produce far less garbage.

An example of this would be if you want to send or receive a Plain Old Java Object (POJO) or FIX Message, the object holding the data can be serialized or deserialized without creating new objects. The objects that are in the pools will remain after a full GC, they will end up in tenured space, where they stay and then have little impact on minor collections.
POJO’s rather than Maps are recycled even when deserialized

Many other libraries use HashMaps as flexible dynamic data structures, but these can create several objects per attribute which in turn later have to be garbage collected by the JVM. In order to avoid this the Chronicle libraries dynamically access real POJO’s with primitives or mutable buffers for fields, this can reduce object creation to zero on deserialization. Most serialization libraries expect to create new objects each time they are deserialized however Chronicle supports using flyweights to deserialize data into existing structures.

All these elements ensure that Chronicle can deliver a solution with almost Zero Garbage Collection and all of the benefits that this will bring

Want access to exclusive Chronicle content?

The Chronicle Community is now live, hit the button below and join the community, for free! You'll get exclusive access to blogs, guides and video content. Join today!

Want more from Chronicle? Subscribe today!

Something went wrong. Please check your entries and try again.