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

[sundararajan.athijegannathan at oracle.com]

Looks good to me.

Minor comments:

* Unused imports in MappedMemoryScope.java

   36 import java.util.ArrayList;
   37 import java.util.List;


* This class could be final explicitly (private constructor)

* Line 63 to 65 could be resource-try to avoid explicit close call

   63         FileChannelImpl channelImpl = (FileChannelImpl)FileChannel.open(path, openOptions(mapMode));


-Sundar

On 06/08/19 6:39 pm, 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
>