Associated MemoryAddress API

[Ty Young]

On 3/3/20 3:16 PM, Maurizio Cimadamore wrote:
>
> On 03/03/2020 19:17, Ty Young wrote:
>>
>> On 3/3/20 12:46 PM, Maurizio Cimadamore wrote:
>>>
>>> On 03/03/2020 18:05, Ty Young wrote:
>>>> Hi,
>>>>
>>>>
>>>> In more OO type memory allocation situations where allocated memory 
>>>> *technically* belongs to another object located in memory, it'd be 
>>>> useful to have an API so that you can associate a MemoryAddress 
>>>> which contains an int pointer to some larger object(struct, for 
>>>> example but could be anything). This would be different than 
>>>> AllocationScope as you don't know how much memory in the end you'll 
>>>> need but you still know it belongs to another MemoryAddress.
>>>>
>>> How is this use case different from slicing an existing memory 
>>> segment? E.g. you can have a memory segment for a big heap array - 
>>> and then you can create a slice segment view of that big segment - 
>>> does that address the use case you mentioned here?
>>
>>
>> Because you need to know how memory is used beforehand.
>>
>>
>> The difference between what exists already(AllocationScope & Arrays 
>> Vs. this) is a top-down vs bottom-up approach. In order to use 
>> AllocationScope & Arrays you need to have some idea of how much 
>> memory you're going to use(top-down). What I'm asking for here is a 
>> bottom-up approach wherein memory can be freely allocated and later 
>> attached(associated) to a parent MemoryAddress.
>>
>>
>> My example of this is NVML and the opaque GPU pointers. When using 
>> bindings for NVML, it would make sense to allocate lots of GPU 
>> specific pointers that can, for example, hold the GPUs utilization as 
>> part of some higher level abstraction API. Since they are bound by 
>> the GPU, they should be freed before the GPU pointer itself is. There 
>> isn't, however, a way to associate MemoryAddress(s) like this.
>>
>>
>> A cool idea that could be implemented if such an API was added is 
>> auto allocating AllocationScope(s) where when the initial 
>> AllocationScope is fully used a new AllocationScope(with same size) 
>> is created that has the one before it set as a parent. You could of 
>> course place limits on how many are created.
>
> So... what you are asking for is, essentially, a way to create an 
> ad-hoc MemorySegment for the entire GPU memory (mostly as a way to 
> attach some temporal bounds to the GPU memory) - and then derive a 
> bunch of MemoryAddresses which are just offset inside this ad-hoc GPU 
> memory segment.
>
> Right?
>
> Now, assuming I understand you correctly, we are considering enhancing 
> the API for creating unchecked segments so that you could e.g .attach 
> your own cleanup actions when close() is called. This would, for 
> instance allow you to 'free' the GPU memory (by calling the right API 
> method) when you are done with it.
>

Unless i'm misunderstanding, this still requires that you know ahead of 
time the amount of memory required. What i'm asking for is a way to 
associate what would otherwise be 100% separate segments with some other 
segment. No memory carving used.


Basically:


MemorySegment seg = MemorySegment.allocateNative(MemoryLayouts.C_POINTER);


MemorySegment segChild = 
MemorySegment.allocateNative(MemoryLayouts.C_POINTER);


segChild = segChild.setParent(seg);


Then when closing seg, it'll also free segChild.


Doing it this way doesn't feel that great though.  Maybe someone else 
has a better way.


> You could also set the size of the (unchecked) GPU segment according 
> to your need (I presume there's some way to know how much GPU memory 
> you've got?).


Not GPU memory, but memory which contains GPU information. Anyway, no 
there isn't a way. That has to be tracked in Panama, which is why i'd 
like API for tracking and management for it.


> At which point a MemoryAddress you derive from such segment would 
> simply be an offset into the GPU memory - which seems to be what you 
> want; and when you call close() on the GPU segment, all addresses 
> derived from it would become invalid.
>
> That said, there would be no support for memory dereference if you go 
> down this path - that is, while you can use MemorySegment and 
> MemoryAddress as abstractions to model GPU memory and offsets to such 
> memory - you wouldn't be able to use a VarHandle to dereference the 
> GPU memory. Well - you could, but you'd have to add quite a bit of 
> adaptation (e.g. reading a GPU-based MemoryAddress would really mean 
> get the MemoryAddress offset, the GPU memory base, and use some native 
> call to do the access - which kind of defeats the point of having a 
> VH, IMHO).
>
> Have I answered your question?
>
> Thanks
> Maurizio
>
>>
>>>
>>> Maurizio
>>>
>>>>
>>>> Could this be done?
>>>>
>>>>
>>>>
>>>>
>>>>