- MappedByteBuffer.hurray()!: Programming the Linux FrameBuffer in Java & VMFlexArray Explained. See here.
- Internet of #allthethings: Using GNURadio Companion to Interact with an IEEE 802.15.4 Network. See here.
What I mean by that, is that when the VM instantiates an integer array object, e.g. int x = new int[ length ], it typically allocates memory (now careful, I'm going to use some C teriminology here) for an object struct (2 uintptr_t in JamVM) which represents the instance of the int object, followed by 1 uintptr_t, which represents the length of the int object, followed by exactly length uintptr_t items (on a 32-bit machine) or length / 2 uintptr_t items (on a 64-bit machine) to represent the data.
VMFlexArrays are slightly different. For the same case as above, where a new int is allocated on the Java heap, the VM would allocate an object struct (2 uintptr_t in JamVM) which represents the instance of the int object, followed by 1 uintptr_t to represent the length of the int object, followed by 1 uintptr_t to point to the int data, followed by the data itself.
What makes VMFlexArrays different, and what makes them flexible (and arguably way better than what most JVMs use today) is that they include that extra uintptr_t to point to the data which could exist anywhere in virtual memory. That means, obviously, VMFlexArrays can point to contiguous data that the JVM would allocate for a regular array, but it also means that it can point to an arbitrary location - and still cooperate with the garbage collector. Indeed, the object lifecycle remains unchanged for VMFlexArrays if the garbage collector avoids releasing memory regions with free(3) if the VMFlexArray pointer does not point to the next contiguous memory address.
VMFlexArray is a solution I came up with that allows one integrate off-heap memory regions into the Java Virtual Machine - e.g. a native external thread that allocates memory using malloc(3), or pages mapped from a device such as /dev/video0 using mmap(2).
Perhaps the aspect of VMFlexArrays that I found most useful, that I somehow forgot to mention during my talk, is that they rather trivially allow the following code snippet to work as expected. Specifically, an IntBuffer derived from a ByteBuffer with a backing array should be able to provide an int backing array view of the same virtual memory.
Currently this code, which should work pretty seamlessly, fails miserably.
With VMFlexArrays, that problem is solved.
I've even used this code to memory map the Linux FrameBuffer and animate a bunch of bouncing balls :-) It works quite well.
There's even a massive speedup associated with access to the underlying byte from a ByteBuffer and even more so viewing the ByteBuffer as an IntBuffer, with access to the underlying int.
I am definitely interested in enabling these changes to make it into OpenJDK, and I feel that the community at large would benefit greatly from them. As my time is rather limited these days, I might prefer to mentor a student to make these changes in the Google Summer of Code, 2015, if OpenJDK was a mentoring organization. Otherwise, I would be open to mentoring a student under the umbrella of JamVM or GNU Classpath as a mentoring organization.