pointer equivalence

[Johannes Lichtenberger]

Do you think it already makes sense to change value based classes (which
might as of now not be immutable) into immutable classes in general and
return for instance a copy each time a field is changed? Considering lack
of time, of course ;-)

kind regards
Johannes

Am Di., 20. Okt. 2020 um 22:07 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

>
> 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
>
>