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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Aug 6 13:51:01 UTC 2019


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
>>


More information about the panama-dev mailing list