MappedMemorySegment & in-memory filesystems

[Maurizio Cimadamore]

On 22/06/2020 14:16, Ty Young wrote:
>
> On 6/22/20 7:44 AM, Maurizio Cimadamore wrote:
>>
>> On 22/06/2020 13:09, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> With libraries such as NVML, the current "allocation scopes" API 
>>> does not properly model the relationship between a GPU and the 
>>> MemoryAddresses/MemorySegments that belong to it. Noticing this 
>>> issue, I've created a solution based on MappedMemorySegments which 
>>> allow for dynamic memory allocation by reusing the same persistent 
>>> on-disk file and simply creating new, larger MappedMemorySegment on it.
>>
>> What is the problem you are trying to solve? In what way the 
>> NativeScope API is not good for your use case?
>
>
> Current(unless it's changed, doesn't look like it has) *unbounded* 
> allocation scopes are not always of one memory chunk but rather 
> multiple chunks thrown into a list. I'd like the ability for memory to 
> be of one continuous chunk, partly for persistence and for 
> consistency. This, along with the fact that files have names, allows 
> me to cleanly associate memory with a specific GPU. Here is how I have 
> it setup currently(although, not everything is in-use):

So, this is, at its core, a way to support reallocation (e.g. "realloc") ?

If that's the main use case, have you tried using a native method handle 
for the "realloc" call plus the unsafe segment factory 
MemorySegment::ofNativeUnchecked?

In other words, I think you should really go down the mapped segment 
path if you care about persistence - if that's not your primary use 
case, I think that's probably not the right tool for the job?

Maurizio

>
>
> https://imgur.com/a/xVR8vCV
>
>
> Every GPU gets its own file(AKA, a "scope") named the same as its UUID.
>
>
>>
>> I'm surprised you ended up with a mapped segment - are you interested 
>> in persisting the memory contents to disk?
>
>
> Currently no, but I've been thinking of doing this. Some GPU data 
> never changes, like UUID, so there is a benefit to doing it for sure.
>
>
>>
>> I guess that, before discussing the specifics, I'd be interested in 
>> learning more about what exactly you are trying to achieve.
>>
>> Thanks
>> Maurizio
>>
>>>
>>>
>>> This works really well and is pretty flexible: you can choose to 
>>> allocate memory in chunks or as-needed(with performance costs, of 
>>> course). It has, however, an issue in that the file needs to be 
>>> stored somewhere. on-disk, like I'm doing now, is an option but it 
>>> of course has disk I/O issues.
>>>
>>>
>>> The good news is that Java supports custom filesystems. The bad news 
>>> is that there is no standardized way to create one within the JDK 
>>> currently, without going with third-party libraries.
>>>
>>>
>>> So my main question here is, would this be something Panama could do?
>>>
>>>
>>> A few other questions:
>>>
>>>
>>> - can anything be to help with MemoryAddress alignment(e.g. a static 
>>> utility method)? I have to do this with my code but I feel like 
>>> there has to be a more standardized way of fixing a MemoryAddress's 
>>> alignment. Even if it's only specific to a MappedMemorySegment, it'd 
>>> be nice to have.
>>>
>>>
>>> - what is the relationship of a MappedMemorySegment and its 
>>> underlying file? It seems like all memory contents are periodically 
>>> written to the file as part of a write-cache or something but I've 
>>> noticed deleting the file on-disk doesn't affect my application in 
>>> the slightest while running. Is this supposed to happen?
>>>
>>>
>>> - could a new method be added to MappedMemorySegment to get an 
>>> expanded view of a file? Something like:
>>>
>>>
>>> public MappedMemorySegment expand(long bytes)
>>>
>>>
>>> ? This is already possible to do with the factory methods but having 
>>> a simple "expand" method would be shorter and easier to read.
>>>