[ACCEPTED]-Any concept of shared memory in Java-shared
A few ways:
Since there is no official API to create 10 a shared memory segment, you need to resort 9 to a helper library/DDL and JNI to use shared 8 memory to have two Java processes talk to 7 each other.
In practice, this is rarely an 6 issue since Java supports threads, so you 5 can have two "programs" run in the same 4 Java VM. Those will share the same heap, so 3 communication will be instantaneous. Plus 2 you can't get errors because of problems 1 with the shared memory segment.
One thing to look at is using memory-mapped files, using Java NIO's FileChannel class 23 or similar (see the map() method). We've 22 used this very successfully to communicate 21 (in our case one-way) between a Java process 20 and a C native one on the same machine.
I'll 19 admit I'm no filesystem expert (luckily 18 we do have one on staff!) but the performance 17 for us is absolutely blazingly fast -- effectively 16 you're treating a section of the page cache 15 as a file and reading + writing to it directly 14 without the overhead of system calls. I'm 13 not sure about the guarantees and coherency 12 -- there are methods in Java to force changes 11 to be written to the file, which implies 10 that they are (sometimes? typically? usually? normally? not 9 sure) written to the actual underlying file 8 (somewhat? very? extremely?) lazily, meaning 7 that some proportion of the time it's basically 6 just a shared memory segment.
In theory, as 5 I understand it, memory-mapped files CAN 4 actually be backed by a shared memory segment 3 (they're just file handles, I think) but 2 I'm not aware of a way to do so in Java 1 without JNI.
These are some tests that I had done a while 2 ago comparing various off-heap and on-heap 1 options.
Shared memory is sometimes quick. Sometimes 13 its not - it hurts CPU caches and synchronization 12 is often a pain (and should it rely upon 11 mutexes and such, can be a major performance 10 penalty).
Barrelfish is an operating system that demonstrates 9 that IPC using message passing is actually 8 faster than shared memory as the number 7 of cores increases (on conventional X86 6 architectures as well as the more exotic 5 NUMA NUCA stuff you'd guess it was targeting).
So 4 your assumption that shared memory is fast 3 needs testing for your particular scenario 2 and on your target hardware. Its not a 1 generic sound assumption these days!
There's a couple of comparable technologies 4 I can think of:
- A few years back there was a technology called JavaSpaces but that never really seemed to take hold, a shame if you ask me.
- Nowadays there are the distributed cache technologies, things like Coherence and Tangosol.
Unfortunately neither will 3 have the out right speed of shared memory, but 2 they do deal with the issues of concurrent 1 access, etc.
The easiest way to do that is to have two 10 processes instantiate the same memory-mapped 9 file. In practice they will be sharing the 8 same off-heap memory space. You can grab 7 the physical address of this memory and 6 use
sun.misc.Unsafe to write/read primitives. It supports 5 concurrency through the putXXXVolatile/getXXXVolatile 4 methods. Take a look on CoralQueue which offers IPC 3 easily as well as inter-thread communication 2 inside the same JVM.
Disclaimer: I am one of the developers 1 of CoralQueue.
Similar to Peter Lawrey's Java Chronicle, you 5 can try Jocket.
It also uses a MappedByteBuffer 4 but does not persist any data and is meant 3 to be used as a drop-in replacement to Socket 2 / ServerSocket.
Roundtrip latency for a 1kB 1 ping-pong is around a half-microsecond.
MappedBus (http://github.com/caplogic/mappedbus) is a library I've added on 9 github which enable IPC between multiple 8 (more than two) Java processes/JVMs by message 7 passing.
The transport can be either a memory 6 mapped file or shared memory. To use it 5 with shared memory simply follow the examples 4 on the github page but point the readers/writers 3 to a file under "/dev/shm/".
It's 2 open source and the implementation is fully 1 explained on the github page.
The information provided by Cowan is correct. However, even 6 shared memory won't always appear to be 5 identical in multiple threads (and/or processes) at 4 the same time. The key underlying reason 3 is the Java memory model (which is built 2 on the hardware memory model). See Can multiple threads see writes on a direct mapped ByteBuffer in Java? for 1 a quite useful discussion of the subject.
More Related questions