[beagle3]

Is there any way to ensure that accessing ByteBuffers (or whatever) is fast?

I had used memory mapped buffers (which should be equivalent in performance), and there was no way to make the JIT inline access to these arrays. It was all calls (indirect, not properly branch predicted at that). Equivalent code to C++, running 10 times slower, with no way to speed it up.

(And the reason I was using memory maps, if you insist -is a 2GB read-only dataset used by multiple processes at the same time - I went to C++ eventually, because there was no way to get reasonable performance from Java, either memory use or speed. This is circa 2010)

[pron]

Yes. High performance Java code sometimes makes use of JVM intrinsics, accessible through the sun.misc.Unsafe class. Those are JITted down to a simple memory access instruction. That class also has intrinsics for CAS, and in JDK 8 it's got intrinsics for different memory fences as well. Those calls are compiled to a single native instruction.

For example, the Java Chronicle library[1] uses these techniques, as well as memory mapped files, to implement fast persistent message queues.

[1]: https://github.com/OpenHFT/Java-Chronicle

[beagle3]

Cool. Was this in Java 6? (circa 2010 - I couldn't find a way to do it back then). Also, why would you need (even on JDK7 or JDK8) unsafe access to jit a memory mapped access inline? Is there an underlying philosophical reason, or is it just that they never got to do it?

[pron]

Yes, it was in Java 6 (except for direct access to fences, which has been added in Java 8).

The sun.misc.Unsafe class is used extensively by JDK classes, and is meant for internal use. It provides intrinsics that are translated to a single machine instruction. Normally, you don't use the class directly. For example, you use, say, AtomicInt for CAS operations (which, internally uses s.m.Unsaafe) or the ByteBuffer class (which internally uses s.m.Unsafe for direct pointer access). The JDK classes add all sorts of protection (like range checks) around s.m.Unsafe, but if you know what you're doing, using s.m.Unsafe directly and eschewing some of those protections (usually adding ones more pertinent to your domain), you get some performance gains which may be significant depending on your use case.