Associated MemoryAddress API

[Ty Young]

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.


>
> Maurizio
>
>>
>> Could this be done?
>>
>>
>>
>>
>>