Unifying memory addresses and memory segments

Thu Sep 29 15:10:00 UTC 2022

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/20220929/a4446927/attachment-0001.htm>