Performance Zone is brought to you in partnership with:

Richard is an empirical technologist and solver of deep-dive technical problems. Recently he has been working on data analytics for high performance computing at jClarity and is writing a book on Java 8 Lambdas for O’Reilly. He is a leader in the London Java Community, sits on their JCP Committee and organises the Adopt-a-JSR programs for Lambdas and Date and Time in Java 8. Richard is also a known conference speaker, having talked at JavaOne, DevoxxUK, Geecon and JAX London. Previously he worked on static analysis problems, verifying part of a compiler and developing automated bug detection technology. He obtained a PhD in Computer Science from The University of Warwick where his research focussed on compiler theory. Richard is a DZone MVB and is not an employee of DZone and has posted 15 posts at DZone. You can read more from them at their website. View Full User Profile

Slab: guaranteed heap alignment on the JVM

07.01.2013
| 4329 views |
  • submit to reddit

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.

Published at DZone with permission of Richard Warburton, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)