pointer equivalence

[Maurizio Cimadamore]

On 20/10/2020 21:17, Johannes Lichtenberger wrote:
> 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 ;-)

I believe this is how the API already works now - 
MemoryAddress/MemorySegment works in terms of immutable, value-based 
classes. This is all to minimize the friction once Valhalla will come 
around, since classes like MemoryAddress, MemoryLayout and MemorySegment 
(esp. when it comes to slicing) can clearly benefit from the "inline 
class" treatment.

I also believe that value-based also implies immutability:

https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html

First bullet says "are final and immutable (though may contain 
references to mutable objects);"

Maurizio

>
> kind regards
> Johannes
>
> Am Di., 20. Okt. 2020 um 22:07 Uhr schrieb Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com <mailto: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
>