pointer equivalence

[Ty Young]

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.


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
>