MappedMemorySegment & in-memory filesystems

[Maurizio Cimadamore]

On 24/06/2020 12:58, Ty Young wrote:
> I wasn't referring to that. What I'm calling suspect was FMA's API for 
> it. According to Wikipedia[1]:
>
>
> I/O errors on the underlying file (e.g. its removable drive is 
> unplugged or optical media is ejected, disk full when writing, etc.) 
> while accessing its mapped memory are reported to the application as 
> the SIGSEGV/SIGBUS signals on POSIX, and the EXECUTE_IN_PAGE_ERROR 
> structured exception on Windows. All code accessing mapped memory must 
> be prepared to handle these errors, which don't normally occur when 
> accessing memory.
>
>
> In other words, if I delete the file or it becomes unreachable, the 
> application should crash from my understanding but it doesn't. I don't 
> know enough about the technical details so that's why I'm asking what 
> the relationship here is. 

I've checked with Alan - and he confirms that Linux keeps reference 
counting of files being mmapped. This means that, even if you delete, 
the file will be held back. On windows, attempting to delete a mapped 
file will actively fail (with exception).

This is demonstrated with the following snippet:

```
import jdk.incubator.foreign.MemoryLayouts;
import jdk.incubator.foreign.MemorySegment;

import java.lang.invoke.VarHandle;
import java.nio.channels.FileChannel;
import java.nio.file.Files;
import java.nio.file.Path;

public class TestMappedSegment {
     public static void main(String[] args) throws Throwable {
         Path f = Files.createTempFile("foo", "txt");
         MemorySegment s = MemorySegment.mapFromPath(f, 0, 100, 
FileChannel.MapMode.READ_WRITE);
         System.out.println("before delete");
         System.in.read(); //1
         f.toFile().delete();
         System.out.println("after delete");
         System.in.read(); //2
         VarHandle handle = MemoryLayouts.JAVA_INT.varHandle(int.class);
         handle.set(s.baseAddress(), 12);
         s.close();
         System.out.println("after close");
         System.in.read(); //3
     }
}
```

If you do an "lsof" you will see that the file is open in both (1) and 
(2). In (3) the file will be no longer be listed by lsof.

AFAIK, the only problematic area with temporal bounds and mapped 
segments (which is also present for mapped buffers) is on file 
truncation (which you can do using the FileChannel API). On truncation, 
the mapped memory is resized behind the segment/byte buffer back, so 
there is an actual chance for things to go really wrong. To mitigate 
this, all memory access routines implemented in Unsafe have a special 
signal handler which listen for SIGBUS events and throw a friendly Java 
exception instead of crashing the VM (this is a behavior that is only 
really possible for mapped files, since the truncated memory won't 
really be made available for anything else by the OS).

Hope this helps.

Maurizio