Shared Memory for IPC?

[Jaromir Hamala]

Hi,

I wonder if anyone has experimented with (posix) shared memory for IPC as a replacement for memory mapped files. It would require a bit of JNI to do the mapping, but it eliminates the disk IO performed by OS when memory mapped files are used, in theory anyway. 

Cheers,

Jaromir

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

[Peter Lawrey]

The problem is that the kernel is involved and you get a latency around 2 micro-seconds.  Given the same messages via shared memory take about 0.2 micro-seconds, this doesn't appear to be a performance gain.  BTW locks between processes in shared memory can be around 0.05 micros and a CAS can be 0.02 micros.

BTW If you use tmpfs, there isn't any disk IO.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jaromir Hamala]

Hi Peter,

thanks for the reply! I expected kernel would be involved in the initial mapping only, isn't it so? 

Is Linux smart enough to not use additional buffers when the memory mapped file is located in tmpfs?

   

[Peter Lawrey]

When you use memory mapping there is only one copy in memory. They OS gets involved ensuring pages are not dirty for too long eg 5 seconds or there are too many eg 10% of main memory. Btw. This doesn't apply to tmpfs.

[Jaromir Hamala]

Thanks! How this works in the case of tmpfs? Let's assume I have a file on tmpfs mapped into a memory. Is the memory address used by the directbytebuffer pointing directly to the same area of physical memory as the file itself? 

[Peter Lawrey]

The MappedByteBuffer.address() point to where the memory has been mapped into the virtual memory of your process.  It can even be mapped multiple times in the same process, but the same underlying main memory is used.

[Peter Lawrey]

When you map the same memory/region of a file multiple times, you get different addresses and multiple entries in /proc/{pid}/maps.  These addresses can be unmapped independently.

[Jaromir Hamala]

I'm afraid I don't understand all aspects of memory management well enough, but I suppose the virtual addresses will be translated to the same physical address as the file (on tmpfs) is using. Therefore if I write to such buffer data goes directly to the memory backing the file and not just to a temporary buffer to be eventually written to the file (unlike the scenario when the file exists on a physical disk) 

[Peter Lawrey]

Correct, there is only one actual copy of the memory.  Writing to the "file" will be visible to all other memory mapping with the same thread safety visibility rule as if the memory was in the same process. e.g. you can use the Compare-And-Swap in one process and it will behave as expected in another process as it is the same memory as far as the CPU is concerned.  I have an example/demo of this I talk about here http://www.slideshare.net/PeterLawrey/thread-safe-interprocess-shared-memory-in-java-in-7-mins

[Martin Grajcar]

Hi Peter,

that's cool. A side question: On page 6 you wrote "likely to go away". Did you mean Unsafe.compareAndSetLong or the whole Unsafe? Why? How will AtomicLong work without it?

Regards,

Martin.

 

[Jaromir Hamala]

I actually attended the excellent lightning talk you gave yesterday - and while I was listening I've got the idea to use shared memory instead of memory mapped file!

Thank a lot for your replies and have a great weekend!

Jaromir  

[Peter Lawrey]

"Going away" is a bit unclear to me. Mostly likely it will be

A) not accessible outside the core code.

B) might be replaced with something standard which AtomicLong can use.

[Peter Lawrey]

Thank you. I am giving a longer talk on this subject at JavaLand. Will put this online too.

[Ben Cotton]

Peter,   For history's sake was it ever stated emperically here  that it now never makes sense to use the real System Vr4 style shared memory (shmop(2),shmat(2),shmctl(2))  system calls as a basis to do shared memory IPC?  I mean other than interactively seeing kernel resident segements/attachments/status/etc. via an `ipcs -m` I would certainly think that the modern non system call tactics (operations via UnSafe, direct/mapped ByteBuffer) would handle "everything" ...  wondering if there still remains any case(s) where it would be necessary to use the old System V IPC system calls directly (over JNI) to affect an otherwise unavailable capability?

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Peter Lawrey]

It is my opinion that memory mapped files are better for performance and easier from Java.

Note, many messaging solutions still use System V ipc so I suspect I am in a minority.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.