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