pointer equivalence

[Johannes Lichtenberger]

Yes, I know :-) In regards to my project this class should be immutable
such that the these references can be aligned next to each other in main
memory in a list:

https://github.com/sirixdb/sirix/blob/master/bundles/sirix-core/src/main/java/org/sirix/page/PageReference.java

Mainly used for a trie based index-structure and has nothing to do with
Panama. But I believe that I should start to work on these optimization as
you do in the JDK itself to get better performance once Valhalla bears some
fruits :-)

Kind regards
Johannes

Maurizio Cimadamore <maurizio.cimadamore at oracle.com> schrieb am Di., 20.
Okt. 2020, 22:21:

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