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

[sundararajan.athijegannathan at oracle.com]

Looks good.

-Sundar

On 06/08/19 7:21 pm, Maurizio Cimadamore wrote:
> Thanks for the comments! Here's a new webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8229181_v2/
>
> Maurizio
>
> On 06/08/2019 14:25, sundararajan.athijegannathan at oracle.com wrote:
>> 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
>>>