Associated MemoryAddress API
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Mar 3 21:16:57 UTC 2020
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.
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?). 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?
>>>
>>>
>>>
>>>
>>>
More information about the panama-dev
mailing list