pointer equivalence

[Johannes Lichtenberger]

Makes sense :-)

I believe in the case of index-structures for database systems it also
makes sense to align index-entries next to each other for best cache-line
usage through locality (that's what in-memory database systems nowadays try
to achieve with node layouts, which should make the best use of
cache-lines. On the JDK these performance optimizations also regarding
vector based SIMD optimizations for the query engine don't really exist,
despite of the intrinsics of Hotspot, but still the fragmented memory might
be a major problem). In our main document index (long-based trie to fetch
nodes/record by it's unique, dense, ascending numeric ID), it might not
make sense, because we can simply compute the index to fetch the right
page-fragment on the next level. However, for instance when implementing a
B-tree or the HOT from Robert Binna it makes a lot of sense to align the
entries next to each other :-)

So, I'm also very much looking forward to the new heap memory layout stuff,
which is hopefully coming in the not so distant future with Valhalla :-)

Kind regards
Johannes

Am Mi., 21. Okt. 2020 um 11:39 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

> Ah sorry - I missed your "in general" :-)
>
> I believe it depends on the use case.
>
> In the case of MemoryAddress/MemorySegment it makes a lot of sense because:
>
> * you can create many slices out of the same segment (e.g. sometimes
> segments are used as cursors)
>
> * often, you need to obtain a base address of a segment in order to pass
> it to some native call
>
> For these reasons, allocation of these structures in Panama is not
> negligible - that's why we're biasing them so much towards Valhalla.
>
> MemoryLayout for instance is a different beast - yes, in principle it is
> immutable, so we could apply same treatment - but a layout is, often,
> instantiated once and kept in a static final variable - is there a lot of
> advantage in making it inline? Probably not as much (thought we might still
> do that).
>
> So I think that, in a lot of cases the answer is "it depends" - on the
> API, and the performance model of your application.
>
> Cheers
> Maurizio
> On 20/10/2020 21:36, Johannes Lichtenberger wrote:
>
> 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
> <https://urldefense.com/v3/__https://github.com/sirixdb/sirix/blob/master/bundles/sirix-core/src/main/java/org/sirix/page/PageReference.java__;!!GqivPVa7Brio!Kr-_GWhcOoydo5fxSuL-bHfkLxsq81ylVtRBJS3eF1TGiHUzuH6AJVknp4l13JCPLf-pVtE$>
>
> 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
>>>
>>>