[foreign-memaccess] RFR 8229181: Add support for mapped memory segments

[Maurizio Cimadamore]

Quick followup,
I've took your patch, followed Alan's advice on how to provide access to 
the JDK mapping capabilities and created a RFR:

https://mail.openjdk.java.net/pipermail/panama-dev/2019-August/006149.html

Comments welcome (either on this thread or on the list).

I've decided to only add a single method, which simplifies the API quite 
a bit - that means that the file should always exist.

Maurizio

On 06/08/2019 14:09, Maurizio Cimadamore wrote:
> Hi,
> this patch adds support for 'mapped' memory segments - that is, memory 
> segments backed by memory-mapped files.
>
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/panama/8229181/
>
> The API is straightforward - it merely adds a new factory to 
> MemorySegment which takes a Path, a size (in long) and a MapMode.
>
> The implementation will create a FileChannel (with the correct 
> inferred OpenOptions), and then map the file using the new 
> 'mapInternal' routine. This will return an Unmapper object which can 
> be used to query properties of the mapping, as well as to unmap the file.
>
> I'd like to thank Steve Dohrmann (who proposed some of the changes in 
> this patch), as well as Alan Bateteman for providing many useful 
> insights on how to tweak the FileChannelImpl internals so that they 
> could be reused from memory segments.
>
> Safety-wise, creating multiple segment from same path should be 
> handled correctlty (as nmap does the right thing here). However Alan 
> pointed me at a possible source of unsafety where the underlying file 
> gets truncated - in which case parts of the mapping becomes invalid - 
> which can crash the VM (with a SIGBUS signal, on Linux). It seems 
> though that, since all our memory access occurs via Unsafe, there are 
> already signal handlers installed by the VM that are prepared to catch 
> these conditions (e.g. access to an unmapped page) - I did a quick 
> test and it seems like that, after a truncate(), memory access fails 
> gracefully (with an exception, not a crash), so I think we should be 
> good here.
>
> Maurizio
>