<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi,<br>
      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).</p>
    <p>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).</p>
    <p>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).</p>
    <p>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. <br>
    </p>
    <p>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).</p>
    <p>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).</p>
    <p>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.</p>
    <p>Maurizio<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 29/09/2022 15:13, Glavo wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAJL5A3k=wk5WXJ20iHrNW6ahACa9+_gdQttqb9z8WL09svMgYQ@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr">Sorry for the late reply to the email. I am more
          concerned about the following things:
          <div><br>
          </div>
          <div>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.</div>
          <div>    The value class as a field type may be able to be
            stored inline in the future. However, this is not possible
            with MemorySegment.</div>
          <div>2. MemorySegment as a function parameter may be more
            difficult to stack allocated when the function cannot be
            inlined.</div>
          <div><br>
          </div>
          <div>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.<br>
          </div>
          <div>If I am wrong, I hope you can point it out for
            me, thanks!<br>
          </div>
          <div>    </div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, Sep 1, 2022 at 5:04
            AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">What Paul says is
            correct, the existing benchmark showed no regression <br>
            before/after the change.<br>
            <br>
            If you know of benchmarks that show a different picture now
            would be the <br>
            ideal time to share them :-)<br>
            <br>
            I also note that, in your original message you wrote about a
            detrimental <br>
            effect on "memory management". What do you mean by that?
            Perhaps you <br>
            mean more objects being created on the heap?<br>
            <br>
            In principle, you can view a MemoryAddress in the old API as
            a <br>
            MemorySegment backed by the global memory session, whose
            base address is <br>
            a certain native address, and its size is zero. So, if
            clients want to <br>
            use a segment just to communicate an address in the new API,
            and they <br>
            create such address-like segments with
            `MemorySegment.ofLong(long)`, all <br>
            should be fine and escape analysis should work roughly the
            same as <br>
            before. But again, if you have evidence of the contrary,
            please let us know.<br>
            <br>
            Thanks<br>
            Maurizio<br>
            <br>
            On 25/08/2022 21:59, Paul Sandoz wrote:<br>
            ><br>
            >> On Aug 25, 2022, at 12:51 AM, Glavo <<a href="mailto:zjx001202@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">zjx001202@gmail.com</a>>
            wrote:<br>
            >><br>
            >> 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.<br>
            >><br>
            > Can you please data you have on any performance
            regressions you are observing?<br>
            ><br>
            ><br>
            >> Do we have some benchmarks to show changes in
            performance and memory overhead (number of temporary objects
            created)?<br>
            >><br>
            > I believe the existing micro benchmarks show no
            regressions:<br>
            ><br>
            >    <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign__;!!ACWV5N9M2RV99hQ!P9lRjFpp2u31-nTmHGkNuffRc8WTHIY7ky-3q570E60HzEm3JKxfI6EqGgQPSLDBEbqIm4qlgjF_sJ6vS5JXRh6N1Q$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign</a><br>
            ><br>
            > Paul.<br>
            ><br>
            ><br>
            >> On Tue, Jul 19, 2022 at 10:05 PM Maurizio
            Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
            wrote:<br>
            >> Hi,<br>
            >> The Java 19 Foreign Function and Memory API (FFM
            API) uses zero-length<br>
            >> memory segments to encode pointers that are
            temporally safe (this<br>
            >> replaces the NativeSymbol abstraction that was
            available in Java 18).<br>
            >> It turns out that there's more to this approach
            than meets the eye, as<br>
            >> memory segments can (with few tweaks) be used as a
            replacement for<br>
            >> memory address everywhere in the FFM API, which
            leads to a simpler and<br>
            >> more symmetric API.<br>
            >><br>
            >> We have captured our findings in the following
            document:<br>
            >><br>
            >> <a href="http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html</a><br>
            >><br>
            >> Cheers<br>
            >> Maurizio<br>
            >><br>
            >><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
  </body>
</html>