1

ChronicleMap on OpenHFT's repository on Github states in their documentation:

  Chronicle Map implements the java.util.concurrent.ConcurrentMap, that stores 
  its data off the java heap.

I've built a compiler and contributed to a few off-shoot languages' compiler implementation. The one's I've worked with allocate everything on the stack (that's what's available during code generation). I've never worked on the JVM and the java compiler, but I do know that typically only the heap and stack are available to allocate instances of classes, local variables, function parameters, etc.

Could someone please explain how we're able to write code, where we can tell the compiler to instantiate data-structures such as the ChronicalMap, have them available to garbage collection by the JVM (and be kept track-of with JVM's general memory management features), but live off the heap?

I've read up on the simple construction documentation and the associate example. I see the how but the reasoning underlying what exactly is going on in-conjunction with the JVM is unclear.

leventov
  • 14,760
  • 11
  • 69
  • 98
Devarsh Desai
  • 5,984
  • 3
  • 19
  • 21
  • 1
    Few Java Developers know you can use off-heap this way, let alone how to write code using it, which is why there is libraries to hide these details. – Peter Lawrey Oct 01 '14 at 18:15

2 Answers2

3

An important thing to remember is that the javac compiler doesn't do much in the way of optimisation, nor does it give you any means of specifying where data is stored or how code should be optimised. (With a few obscure exceptions in Java 8 like @Contended)

Java derives much of it's extensibility from libraries which generally operate at runtime. (There is often a build time option as well) A key thing to realise is that a Java program can generate and alter code while it is running, so in fact much of the smarts are happening at runtime.

In the case of off-heap usage, you need a library which supports this functionality and this will directly, or indirectly use sun.misc.Unsafe (On most popular JVMs) This class allows you to do many things the language doesn't support, but is still really useful to have if you are a low level library builder.

While off heap memory is not directly managed by the GC, you can have proxy objects e.g. ByteBuffer which have a Cleaner so that when these objects are GC-ed the off heap memory associated with it is also cleaned up.

Disclaimer, I wrote most of ChronicleMap.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    Peter, thank you for the great answer and a little bit of the in depth look into ChronicleMap, I'll look into `sun.miscm.Unsafe` and `Cleaner,` and read up more on them. Also I'm a big fan of many of your answers on S.O., thank you! (small world seeing as how you wrote ChronicleMap, didn't see that coming! haha) Hope you have a great week ahead! – Devarsh Desai Oct 01 '14 at 18:19
  • 1
    @DevarshDesai My company is http://openhft.net/about-company/ I need to get a new photo ;) – Peter Lawrey Oct 01 '14 at 18:20
1

The term off heap refers to the ability to use "raw" memory buffers in java. these maybe regular memory buffers from the process address space, or memory mapped files.

These buffers are "raw" - you manage their content yourself - they are not managed by the garbage collector.

Ophir Yoktan
  • 8,149
  • 7
  • 58
  • 106