pointer equivalence
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Oct 21 09:39:40 UTC 2020
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
> <mailto: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
>> <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
>>
More information about the panama-dev
mailing list