No segment method for MemoryAddress?

[Maurizio Cimadamore]

On 25/08/2020 19:05, Ty Young wrote:
>
> On 8/25/20 5:46 AM, Maurizio Cimadamore wrote:
>>
>> On 25/08/2020 10:14, Ty Young wrote:
>>>
>>> On 8/24/20 3:12 AM, Maurizio Cimadamore wrote:
>>>>
>>>> On 22/08/2020 03:45, Ty Young wrote:
>>>>> Doing that increases the amount of generic type declarations for 
>>>>> static methods which are already decently sized:
>>>>>
>>>>>
>>>>> public static <T, E extends NativeValue<T>> E 
>>>>> ofUnsafeValueLayout(MemoryAddress address, ValueLayout layout) 
>>>>
>>>> Without knowing exactly what your code is doing - this seems 
>>>> similar to what we do in jextract to expose global variables (e.g. 
>>>> create unsafe segments based at a certain address, with given size).
>>>
>>>
>>> It's dual purpose - it can be used to create a usable object 
>>> directly from native or interpret that MemoryAddress as the desired 
>>> NativeValue given the layout.. but that's irrelevant.
>>>
>>>
>>> How are you supposed to create/use method handles with this new 
>>> setup? Do native bindings now return MemorySegment instead of 
>>> MemoryAddress? Or does it not matter because of Addressable?
>>
>> Method handles works as before. If you want to pass structs by value, 
>> you need MemorySegment, if you pass pointer you need MemoryAddress. 
>> The only thing affected by this is memory deference with var handle.
>
>
> That's interesting, I've been using MemoryAddress for structs this 
> whole time without issues. What about arrays?
If you got a MemoryAddress from C code, and then tried to dereference 
with a memory var handle, that will blow up. If it never does, it means 
you must have some logic which creates an unchecked segment.
>
>
> *snip*
>
>>>
>>>
>>> 1. for creating a new NativeObject using a layout(often no-args 
>>> default constructor)
>>>
>>>
>>> 2. for interpreting an existing MemorySegment as another existing 
>>> NativeObject
>>>
>>>
>>> 3. for MemoryAddress pointers returned from C
>>>
>>>
>>> I guess the roles are more distinguished this way(no dual purpose as 
>>> mentioned above), but adding more static methods/constructors isn't 
>>> desirable especially when the code path is basically the same anyway.
>>
>> What is NativeObject? Is it an abstraction to model structs? Again, I 
>> can't comment on an API I only vaguely remember.
>
>
> NativeObject is basically just a marker interface used for generic 
> return types, at least now. I used to have segment methods in it so I 
> didn't have to do <NativeObject>.getAddress().segment().asSlice() 
> everytime, but the segment part had to be removed because of the 
> Addressable change which broke my project.
And I think that's a good thing. From the sound of what you say, the 
more natural thing for your NativeObject API is to be based on a 
segment, rather than an address, especially if you expect it to be 
dereferenceable.
>
>
>>
>> But it appears to me that these cases are all very different; if you 
>> create something from scratch you know exactly spatial and temporal 
>> bounds. If a C slips you a pointer, you know nothing and you have to 
>> make up spatial and temporal bounds (with an unsafe segment, likely). 
>> So it makes sense to me to have at least two overloads there.
>>
>> As for the reinterpreting, that's basically a view over an existing 
>> segment, so that's a different one, yes.
>>
>> I'm not sure what the problem is here - that you need an extra 
>> overload for MemoryAddress while before you just took a segment and 
>> you just called address.segment() ? Do you realize that 
>> address.segment() would have returned NULL in many cases?
>
>
> The libraries that I use(NVML, NVCtrl) rarely return pointers and even 
> when they do they are immediately made safe by my abstraction layer:
>
>
> public static NativeArray<Byte> nvmlErrorString(nvmlReturn_t value) 
> throws Throwable
> {
>     return 
> NativeArray.ofUnsafeSequenceLayout((MemoryAddress)ERROR_STRING.getMethodHandle().invoke(value.getNativeValue()), 
> ERROR_LAYOUT);
> }
>
>
> So basically it's impossible for a MemoryAddress to not have segment. 
> Of course functions are an exception.

Ok - that's what I was hinting at.

But if that's the case - you can simply replace MemoryAddress with 
MemorySegment inside NativeObject and that should work as before?

Maurizio

>
>
>>
>> Maurizio
>>
>>
>>>
>>>
>>>>
>>>> Maurizio
>>>>