Unifying memory addresses and memory segments

[Glavo]

Thank you very much for your clarification, although I think some of them
still need a very long wait...

Also, I'll ask another, unrelated little question by the way: How to
specify calling convention (cdecl / stdcall) in Valhalla? I didn't find
anything relevant, am I missing something?

On Thu, Sep 29, 2022 at 11:10 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> There are few things to be clarified here. Not all segments are created
> equals. If you create a segment and attach it to a "real" session, then
> escape analysis will fail (as the segment needs to be added to the
> session's list).
>
> But the segments returned by the linker (which used to be MemoryAddress
> instances) are simpler segment instances, which are backed by the "global"
> session. These instances are routinely scalarized (I believe folks working
> on LWJGL did some experiments on this, and reported few issues, which have
> now been fixed).
>
> Of course, if you take a zero-length memory segment, associated with the
> global session, and want to give it a size and a session (using
> MemorySegment::ofAddress), that's more expensive (but that is the same as
> before).
>
> Lastly, I don't think there's anything preventing us from turning
> MemorySegment into value classes, on paper. The tricky thing of doing that
> move is to make sure that C2 can see "what kind of segment are you dealing
> with", so that the underlying Unsafe access (for memory operation) can be
> sharp. In other words, C2 needs to know if the segment has an associated
> "heap base" (and, if yes, what's the type of the base object) or not.
> Otherwise you end up with the so called "mixed access", where C2 wasn't
> able to prove that access was off-heap and extra barriers are inserted.
>
> That is why, at the moment, we have different memory segment
> implementations, one per "kind". We have an abstract class, and many
> leaves. Valhalla supports abstract classes too, but abstract classes need
> to have no field (which is something we can easily fix when needed).
>
> But I think the biggest gains would come from having a truly monomorphic
> memory segment implementation, although that requires some C2 optimizations
> (such as speculating on the types of some fields) which we do not have yet
> (but which will likely get more attention once Valhalla lands, as
> monomorphi-zation will become a trick that many people will want to play).
>
> So, in short - the proposed patch doesn't really alter performance
> characteristics (zero-length segments backed by global session are cheap to
> create and scalarize, like MemoryAddress). And I think there's no issue in
> making MemorySegment a value class, although, to fully reap benefits of
> Valhalla we might need more help from C2.
>
> Maurizio
>
>
> On 29/09/2022 15:13, Glavo wrote:
>
> Sorry for the late reply to the email. I am more concerned about the
> following things:
>
> 1. I've asked about Panama's interaction with Valhalla in previous
> emails. At the time you said that MemoryAddress might become a value class
> in the future.
>     The value class as a field type may be able to be stored inline in the
> future. However, this is not possible with MemorySegment.
> 2. MemorySegment as a function parameter may be more difficult to stack
> allocated when the function cannot be inlined.
>
> I'd like to be able to make native calls through Valhalla with zero
> allocation, but this change seems to be further away from my expectations,
> so I'm skeptical.
> If I am wrong, I hope you can point it out for me, thanks!
>
>
> On Thu, Sep 1, 2022 at 5:04 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> What Paul says is correct, the existing benchmark showed no regression
>> before/after the change.
>>
>> If you know of benchmarks that show a different picture now would be the
>> ideal time to share them :-)
>>
>> I also note that, in your original message you wrote about a detrimental
>> effect on "memory management". What do you mean by that? Perhaps you
>> mean more objects being created on the heap?
>>
>> In principle, you can view a MemoryAddress in the old API as a
>> MemorySegment backed by the global memory session, whose base address is
>> a certain native address, and its size is zero. So, if clients want to
>> use a segment just to communicate an address in the new API, and they
>> create such address-like segments with `MemorySegment.ofLong(long)`, all
>> should be fine and escape analysis should work roughly the same as
>> before. But again, if you have evidence of the contrary, please let us
>> know.
>>
>> Thanks
>> Maurizio
>>
>> On 25/08/2022 21:59, Paul Sandoz wrote:
>> >
>> >> On Aug 25, 2022, at 12:51 AM, Glavo <zjx001202 at gmail.com> wrote:
>> >>
>> >> It looks good in terms of simplifying API design, but this seems to
>> have some detrimental effects on performance optimization as well as memory
>> management.
>> >>
>> > Can you please data you have on any performance regressions you are
>> observing?
>> >
>> >
>> >> Do we have some benchmarks to show changes in performance and memory
>> overhead (number of temporary objects created)?
>> >>
>> > I believe the existing micro benchmarks show no regressions:
>> >
>> >
>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign__;!!ACWV5N9M2RV99hQ!P9lRjFpp2u31-nTmHGkNuffRc8WTHIY7ky-3q570E60HzEm3JKxfI6EqGgQPSLDBEbqIm4qlgjF_sJ6vS5JXRh6N1Q$>
>> >
>> > Paul.
>> >
>> >
>> >> On Tue, Jul 19, 2022 at 10:05 PM Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>> >> Hi,
>> >> The Java 19 Foreign Function and Memory API (FFM API) uses zero-length
>> >> memory segments to encode pointers that are temporally safe (this
>> >> replaces the NativeSymbol abstraction that was available in Java 18).
>> >> It turns out that there's more to this approach than meets the eye, as
>> >> memory segments can (with few tweaks) be used as a replacement for
>> >> memory address everywhere in the FFM API, which leads to a simpler and
>> >> more symmetric API.
>> >>
>> >> We have captured our findings in the following document:
>> >>
>> >> http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html
>> >>
>> >> Cheers
>> >> Maurizio
>> >>
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220930/a1c1dfdd/attachment.htm>