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

[Maurizio Cimadamore]

Please ignore this email - it was sent by mistake :-)

Maurizio

On 06/08/2019 14:11, Maurizio Cimadamore wrote:
> 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
>>