pointer equivalence

[Maurizio Cimadamore]

On 21/10/2020 20:35, Ty Young wrote:
>
> I feel like the context is being completely missed here. I want to use 
> an object from native memory in a **WeakHashMap** just as if it was 
> allocated on-heap. Since VarHandle.get() returns new object instances 
> the pointers aren't equal and it will fail.

Actually - VarHandle::get doesn't return "object instances" (the var 
handles only return primitive types), so I'm sorry but I don't follow.

Maurizio

>
>
> On 10/20/20 3:04 PM, Maurizio Cimadamore wrote:
>>
>> On 20/10/2020 19:44, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> Is there any plans to make pointer equivalence(==) work for objects 
>>> that are derived from native memory, so that:
>>>
>>>
>>> MemorySegment segment = 
>>> MemorySegment.allocateNative(MemoryLayouts.JAVA_LONG);
>>>
>>> VarHandle handle = MemoryHandles.varHandle(long.class, 
>>> ByteOrder.nativeOrder());
>>>
>>> handle.set(segment, 0, 500);
>>>
>>> Long valuePointer = (Long)handle.get(segment, 0);
>>>
>>> Long valuePointer2 = (Long)handle.get(segment, 0);
>>>
>>> System.out.println(valuePointer == valuePointer2);
>>>
>>>
>>> prints true.
>>
>> Hi
>>
>> I don't see how this is related with the memory access API to be 
>> honest. You just read a `long` (lower case L), you box it into some 
>> wrapper object (j.l.Long) but that is a completely separate process. 
>> The Long you get back has nothing to do with the memory access API.
>>
>> And, using == on wrapper instances is bogus anyway: the JDK caches 
>> some of the values, to avoid spinning to many instances. So certain, 
>> for certain ranges, it looks like == works, while for other it doesn't.
>>
>>
>>>
>>>
>>> I'm guessing as-is if valuePointer was to go out-of-scope while 
>>> being part of a WeakHashMap, the WeakHashMap key would be removed. 
>>> It seems like everything stored in-memory is just a value as far as 
>>> Java is concerned, and the number classes, along with MemoryAddress, 
>>> just create new instances or point to cached ones.
>>>
>>>
>>> I'm more interested in pointer equivalence when it comes to 
>>> MemoryAddress than numbers as it could be useful in creating 
>>> automatically managed native memory heaps. This, along with the fact 
>>> that MemorySegment.address() returns a new MemoryAddress instance(is 
>>> this a bug?) kinda throw a wrench into some ideas on how to make one.
>>>
>> A MemoryAddress already supports equals - not sure why you think == 
>> would be an improvement over that. Note that MemoryAddress is also 
>> marked as a "value based classed" because we'd like to make these 
>> things inline classes when Valhalla is ready. When that happens == 
>> might just be a more compact form to write .equals (since == on 
>> inline instances compares them by contents).
>>
>> As for MemorySegment::address returning a new address - again, when 
>> Valhalla will be around there will be no way for you to tell whether 
>> it's a new instance or not. In general, you should not make 
>> identity-based assumptions on 
>> MemorySegment/MemoryAddress/MemoryLayout beause they are all going to 
>> fail when the world transitions to Valhalla (which is why the javadoc 
>> says so).
>>
>> Maurizio
>>