Unifying memory addresses and memory segments

[Glavo]

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
> >
> > 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/20220929/333ba221/attachment.htm>