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
