Beyond ByteBuffers by Brian Goetz


Accessing foreign (e.g. off-heap) memory from a Java application can be useful for a number of reasons, from avoiding the costs associated with garbage collection, to sharing memory across multiple processes and/or with native code. Yet, to date, the Java SE API provides no official tools for accessing foreign memory, forcing developers to cope with less than ideal solutions. One such solution, perhaps the most widely used, is the ByteBuffer API, which allows the creation of so called “direct” byte buffers — thus allowing users to manipulate off-heap memory directly from Java.

Another, less common, avenue by which developer can access foreign memory from Java code is through the Unsafe API, which exposes several low-level functionalities to manipulate both off-heap and on-heap memory directly, and in a very efficient fashion, thanks to its clever use of JVM intrinsics.

Unfortunately, existing approaches for accessing foreign memory are far from being ideal: on the one hand, the ByteBuffer API, which has been designed after I/O use cases, suffers from several limitations — lack of addressing space, non-deterministic deallocation to name a few — when used as a general purpose foreign memory API; on the other hand, using the Unsafe API — as the name implies — is a risky business, which can result in hard JVM crashes if the API is not used correctly.

In other words, when it comes to accessing foreign memory, no optimal solution exists – and Java developers are faced with a dilemma: should they use the safe, trodded but twisted (and possibly less efficient) ByteBuffer path or should they abandon all safety guarantees and embrace the (unsupported) Unsafe API?

In this talk we paint the path to the future: a safe, supported and efficient foreign memory access API for Java. By providing a more targeted solution to the problem of accessing foreign memory, not only developers will be freed by the limitations of the existing APIs – but they will also enjoy improved performances, as the new API will be designed from the ground-up with JIT optimizations in mind – and all without sacrificing memory access safety.

Brian Goetz is the Java Language Architect at Oracle, and was specification lead for JSR 335 (Lambda Expressions for the Java Language.) He is the author of the best-selling book “Java Concurrency in Practice” and is a frequent presenter at major industry conferences.



  1. One thing I don't understand is why when I used direct buffers, I would still get out of memory errors trying to allocate relatively small amounts of memory, as if it was still trying to grab memory off the Java heap. This is on Android at least I see this behaviour. I had to make my own 'native buffer' class which allocates memory via malloc in C over JNI and returns a buffer object back to Java. I thought allocateDirect was supposed to do this for me but apparently on Android it does not.

  2. Could there be "bridge" between records and this API – eg. to get memory layout for record which would allow to store records (or record data actually not the instance itself) in off-heap memory.


Please enter your comment!
Please enter your name here