Memory mapped files in java: too many questions?

Question

Memory mapped files are (according to the spec) largely dependent on the actual implementation of the OS and a number of these unknown aspects are already explained in the javadoc. However I have some additional questions and not sure where to turn to for answers.

Suppose application A maps a file to memory from position=0 to size=10.

I would assume the OS needs a continuous piece of memory to map it? Or is this dependent on implementation?

Now suppose we have an application B that maps from position=0 to size=11. Are the first 10 bytes shared or is it an entirely different mapping? This relates back to the continuous memory question.

If we want to use mapped files for IPC, we need to know how the data is reflected in other applications, so if B writes to memory, does A see this?

However as I read the spec, this depends on the OS. This makes it dangerous to use for general purpose IPC as it destroys portability right?

Additionally suppose the OS does support it, so B writes to memory, A sees the change, what happens if we do this:

B.write("something");
A.write("stuff");
A.read();

What exactly will A read?
Or put otherwise:

how are the file pointers managed?
How does it work with concurrency, is there cross application locking?

Answer 1

You can assume that every operating system will perform the memory mapping in terms of blocks which usually have a size which is either a power of two of a multiple of a power of two and significantly larger than 11 bytes.

So regardless of whether you map from 0 to 10 or from 1 to 11, the underlying system will likely establish a mapping from 0 to blocksize to a logical address X which will be perfectly hidden to the Java programmer as the returned ByteBuffer has its own address pointer and capacity so it can always be adjusted so that, e.g. position 0 yield to address X + 1. But whether the underlying system or Java’s MappedByteBuffer performs the necessary translation is not important.

Usually, operating systems will end up using the same physical memory block for a mapping to the same region of the same file so it is a reasonable way of establishing IPC, but as you have already guessed, that is indeed OS dependent and not portable. Still, it might be useful if you make it optional and let the user who knows that his system supports it, can enable it.

Regarding your question about the two writes, of course, if two applications write to the same location concurrently, the result is entirely unpredictable.

Mapping a file region is independent from locking but you may use the file channel API to lock the region you are mapping to gain exclusive access.