Slab: guaranteed heap alignment on the JVM

The Problem

Over time CPU clockrates have gotten considerably faster, but Memory Speed has failed to catch up. In order to make good usage of modern CPUs it's important to consider data structure alignment in memory, in order to work in sympathy with the On-CPU Cache. In other words you want good Locality of Reference.

Unfortunately the Java Platform's decision to abstract away memory allocation patterns makes it hard to guarantee properties about your memory allocation. In most situations this is a blessing: you simply don't need to worry about where your memory is coming from or going! There are some scenarios where you're implementing an algorithm that requires layout guarantees and Java falls short in this regard.

Existing Solutions

Java provides several mechanisms that offer more direct access to memory, for example the ByteBuffer and the notorious Unsafe class. Unfortunately heavy usage of these classes can quickly turn a codebase into an unstructured mess.

Recently Martin Thompson described a way of more cleanly managing these access patterns. His solution wraps up the access logic using the Flyweight Pattern. This still has the downside of having to manually implement some boilerplate and take with pointer arithmetic.

Slab: A Better Solution

Slab is an experiment to simplify the existing solutions by wrapping the boilerplate code and pointer access up into a library. The idea is simple: the user provides an interface that defines their datatype, and the library implements the underlying getters and setters via the Unsafe class. Here's a simple code example, that should demonstrate how it works:

// Define your DataType
public interface GameEvent extends Cursor {
  public int getId();
  public void setId(int value);
  public long getStrength();
  public void setStrength(long value);
}

// Create an allocator for your DataType
Allocator eventAllocator = Allocator.of(GameEvent.class);

// Allocate 100 off heap GameEvent instances - sequentially in memory
GameEvent event = eventAllocator.allocate(100);

// Move to the index of the instance that you want to read from or write to
event.move(1);

// set and get values like a normal POJO
event.setId(6);
assertEquals(6, event.getId());

Conclusions and Future Work

The source code is available on github.

This was a fun little experiment, but there's certainly a few obvious improvements that could be made:

• Support Abstract Classes as well as Interfaces, in order to support proper classes, and not just tuple-style data structures.
• Expose statistics about memory allocated, and allocation times - similar to GC Logs or MXBeans.
• Support multiple flyweights for a slab of memory.
• Experiment with concurrency access patterns - eg operations built on CAS that directly operate on the underlying memory.
• Nested Objects.
• Resizing slabs.
• Investigate automated memory management - unfortunately the only way I can think of doing this is through finalizers, which have their own downsides.

I plan to implement these soon, but its always good to release open source code early and often. Any feedback is welcome.