Bug: MappedMemorySegmentImpl uses internal FileChannelImpl

[Ty Young]

On 6/29/20 1:04 PM, Maurizio Cimadamore wrote:
>
> On 29/06/2020 18:49, Ty Young wrote:
>>
>> On 6/29/20 11:32 AM, Maurizio Cimadamore wrote:
>>> Note that to be able to map a file we need a file descriptor. The 
>>> file system you provided has support for channels, etc. but note 
>>> that the channels implementation do not support mapping using 
>>> MappedByteBuffer:
>>>
>>> https://github.com/google/jimfs/blob/master/jimfs/src/main/java/com/google/common/jimfs/JimfsFileChannel.java#L592 
>>>
>>>
>>> So I don't really see how we could make this work. At the end of the 
>>> day, MemorySegment.mapFromPath has to end up calling `mmap` - and we 
>>> need to be able to retrieve the parameters of the mmap call from 
>>> somewhere.
>>
>>
>> Would FMA having its own platform independant mmap bindings be a 
>> possible solution? I guess I could just do it myself either way.
>
> I think I showed an example of how to create a mapped segment 
> manually, by relying on FFI:
>
> https://gist.github.com/mcimadamore/128ee904157bb6c729a10596e69edffd
>
> If you happen to have a file descriptor for the thing you want to map, 
> then an approach like this would be feasible


To be clear, will FMA ever stop using internal details and what I'm 
trying to achieve be possible using *just* JDK APIs? Surely FMA 
shouldn't dictate this and lockout every custom FileSystem implementation?


>
> Maurizio
>
>>
>>
>>>
>>> Maurizio
>>>
>>>
>>> On 29/06/2020 16:55, Ty Young wrote:
>>>> Tried using Google's in-memory filesystem:
>>>>
>>>>
>>>> https://github.com/google/jimfs
>>>>
>>>>
>>>> for storing mmap files but ran into an issue because 
>>>> MappedMemorySegmentImpl uses internal FileChannelImpl method:
>>>>
>>>>
>>>> https://github.com/openjdk/panama-foreign/blob/acc11115db42cc0e17efdf361d58c65f4e922f39/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java#L105 
>>>>
>>>>
>>>>
>>>> which causes a class casting exception when using Google's 
>>>> in-memory Java filesystem and probably other implementations as well.
>>>>
>>>>
>>>>