Over a million developers have joined DZone.

Slab: guaranteed heap alignment on the JVM

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

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

// set and get values like a normal POJO
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.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.


Published at DZone with permission of Richard Warburton, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}