pointer equivalence

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Oct 20 20:04:59 UTC 2020


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



More information about the panama-dev mailing list