anchor.diff:  }
   ----
   
  -`AbstractMarshallable` provides efficient, generic `toString`, `equals` and `hashCode` as well as  `readMarshallable` and `writeMarshallable` for Serialization.  If you can't extend this class you can implement the `Marshallable` interface.
  +`AbstractMarshallable` provides efficient, generic `toString`, `equals`, and `hashCode`, as well as  `readMarshallable` and `writeMarshallable` for serialisation.  If you cannot extend this class, you can implement the `Marshallable` interface.
   
   .Dump of a queue in a unit test
   [source, java]
  
positive.code:   lastAcknowledgedIndexReplicated: 0 # <6>
  }
  ----
  <1> the first message is meta data written in binary
  <2> the type of header is aliased as the name SCQStore.
  <3> the `writePosition` is the first bound value. It is the highest known byte which has been written to and is updated atomically.
  <4> the roll cycle is daily.
  <5> this class controls how it will be indexed on demand.  This adds meta data entries for indexed lookup.
  <6> this is the highest message index which was acknowledged by a replica.
  
  For us a key feature of CQ is not just how the data structure is arranged,
  but also how transparently this binary data structure can be inspected.
  
  NOTE: The `SCQStore` "bootstraps" the queue itself.  If you provided another, custom implementation the queue could behave as you wish, provided it support the same interface.  The Rolling and Indexing strategies can also be customized.
  
  If we look at the last message, you can see the message type, the type of the payload and the value of all the fields.
  
  [source, java]
  ----
  
negative.code: # 83885663 bytes remaining
  ----
  
  You will note that `YAML` supports `typed data`, `enumerated values`, `comments`, and message `start` and `end` markers.
  
  === Append-only data structure
  
  Chronicle Queue is design for sequential writes and reads.  It also supports random access, and updates in-place. Although you cannot change the size of an existing entry, you can pad an entry for future use.
  
  This append-only structure is more efficient for passing data between threads using the `CPU L2 cache` coherence bus, It can also be faster than attempting to pass an object between threads, as it avoids random access which can be
  common in `Java` objects where there can be a lot of reference chasing.
  
  It is also more efficient for persistence to disk; HDD and SSD are much more efficient when being accessed sequentially.
  
  The append-only structure makes replication much simpler as well.
  
  === Unbounded memory mapped files
  
  Chronicle Queue is built on a class called `MappedBytes` in `Chronicle-Bytes`.
  This visualises the file to act as an unbounded array of bytes mapped to a file.
  As you append data, it will add memory mappings transparently. The file grows as you write more data.
  
  The key benefit of using memory-mapped files, is that you are no longer limited by the size of your `JVM`, or even the size of your main memory.  You are only limited by the amount of disk space you have. If you want to load `100` TB into a `JVM` for replay the operating system does all the heavy lifting for you.
  
  Another benefit of using a memory-mapped file is the ability to bind a portion of memory to an object.
  The key attributes in the header are bound when first loading, and after that whey work like a normal object, updating off-heap memory and the file in a thread-safe manner.
  You can perform operations like `compareAndSet`, `atomic add`, or `set max value` (a set which only ever increases the value).
  As the data access is thread-safe, it can be shared between threads, or processes, as fast as the time it takes for an L2 cache miss; up to `25` nano-seconds.
  
  === The data structure in more detail
  
  Each record is a "Size Prefixed Blob", where the first four bytes contain a `30` bit length of the message. The top two bits are used to record:
  
   - whether this message is user-data, or meta-data required to support the queue itself,
   - a bit to flag whether the message is complete or not.
  
  When the message is not complete, it cannot be read.  However, if the length is known, a writer can skip such messages, and attempt to write after it.
  
  For example:
  
  `Thread1` is in the middle of writing a message, but it knows the message length; it can write `4` bytes which indicate the length.
  
  `Thread2` can see that there will be a message, and skip over it looking for a place to write.
  
  In this way, multiple threads can be writing to the queue concurrently.
  Any message which is detected as bad (for example, the thread died), can be marked as meta-data and skipped by the reader.
  
  There is a special value ("poison pill" value), which indicates the file has been rolled. This ensures that all writers and readers roll at the same point, in a timely manner.
  
  *Header example*:
  
  [source, yaml]
  ----
  