atomix-storage's JournalSegment is shared for all storage levels, but has special case handling from StorageLevel.MAPPED. Furthermore initial segment read (for indexing purposes) always uses StorageLevel.DISK-based logic.

With CONTROLLER-2043, CONTROLLER-2096 and CONTROLLER-2098 it is clear that there are four things that are happening:

1. JournalSegment owns the FileChannel
2. on instantiation (i.e. loadSegment()-time), the file is read to populate index and establish the last written entry
3. if StorageLevel.MAPPED is used, then we have a MappedByteBuffer attached to the writer
4. JournalSegment dances around the writer implementation, switching back and forth, i.e. at idle it uses FileChannel writer – presumably to reduce MappedByteBuffer overhead – but that ends up costing us heap due to FileChannelJournalSegment.memory

We need to specialize JournalSegment, so that the MappedJournalSegment manages the MappedBuffer separately from the writer – allowing the readers to be managed separately from the writer – hence allowing JournalSegmentWriter.close() do the same thing JournalSegmentReader.close().