<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 15/01/2024 11:37, 刘希晨 wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CABUmArQcvJgUBo4C60FQ5pgY1JEAxhb+K1nQxk60TcHckYjR3Q@mail.gmail.com">
      
      <div dir="ltr">Thanks for your answers, that really helps.
        <div><br>
        </div>
        <div>I got another question about using MemorySegment in
          JDK22-ea, I noticed that MemorySegment.getString() and
          MemorySegment.setString() were added for string manipulation,
          but it's not so convenient to use, because after the invoking
          of MemorySegment.getString() and MemorySegment.setString(),
          there are no way to track the offset of current memorysegment,
          which should be tracked by developers, and StringSupport is an
          internal class, which couldn't be directly used by developers.</div>
      </div>
    </blockquote>
    <p>In reality these methods have always been there even in previous
      iterations, under a different name (getUtf8String/setUtf8String).
      What has changed is that now it is possible to select a custom
      Charset to do the string encoding/decoding.</p>
    <p>I guess you refer to the fact that e.g. getString gives you a
      Java string, but you don't know how many bytes have been decoded?
      E.g. you'd want something that acted both as string dereference
      and strlen at the same time. This is a bit harder to do, as that
      would require some cumbersome method signature (e.g. a method
      returning a record with the string and its underlying byte
      length).</p>
    <p>While we don't plan to make further changes to the API in 22 at
      this stage, it would be helpful if you could describe your use
      case more precisely (e.g. even with some pseudocode) to make sure
      we understand it correctly. The main use case for get/setString
      is, currently to either:</p>
    <p>* convert a Java string into a native segment, so that it can be
      passed to a native function<br>
      * convert a native memory segment back into a string - this can be
      either a string stored in memory (e.g. struct field), a native
      function return, a global variable, ...</p>
    <p>In such cases (especially the latter), the information about the
      "offset" after a string decoding is not too important - e.g. if
      you have a struct whose field is a char*, and you want to read
      that field as a string (which is very common), something like
      getString gets the job done. The case where the offset info might
      be helpful is when multiple strings are encoded "back to back", so
      that you need to issue multiple "getString" at different offsets.
      Is that the use case you have in mind?</p>
    <p>Thanks<br>
      Maurizio</p>
    <blockquote type="cite" cite="mid:CABUmArQcvJgUBo4C60FQ5pgY1JEAxhb+K1nQxk60TcHckYjR3Q@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Regards.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">jorn.vernee@oracle.com</a>>
          于2024年1月13日周六 19:27写道:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <div>On 12/01/2024 22:46, Maurizio Cimadamore wrote:<br>
            </div>
            <blockquote type="cite">
              <div>On 12/01/2024 19:34, Pedro Lamarão wrote:<br>
              </div>
              <blockquote type="cite">
                <div dir="ltr">...<br>
                  <div class="gmail_quote">
                    <div>May I suggest that the following be added to
                      the Javadoc?</div>
                    <div>It is already stated that it is advised that
                      critical downcalls be "extremely fast".</div>
                    <div>I suggest adding that they should run in a
                      predictable, "constant" amount of time.</div>
                  </div>
                </div>
              </blockquote>
              I agree that the text could be improved - however we don't
              say "fast" - we say this:<br>
              <p> </p>
              <blockquote type="cite">
                <p> A critical function is a function that has an
                  extremely short running time in all cases (similar to
                  calling an empty function), and does not call back
                  into Java (e.g. using an upcall stub). </p>
              </blockquote>
              I agree that talking about "constant" or "predictable"
              execution time would perhaps be a better characterization.</blockquote>
            <br>
            <p>This is what the "in all cases" is meant to convey. i.e.
              if in <i>some</i> cases the function doesn't have an
              extremely short running time, it should not be marked
              critical.</p>
            <p>But, I think the best advice is: don't just use
              critical() anywhere that you can, use it only in places
              where you absolutely need it. As Maurizio said as well,
              the difference when using critical() is very small, but it
              blocks the rest of the JVM from doing its job (not only
              the GC, but also other safepoint-/handshake-based
              operations). So, I'd say the right way to use critical()
              is to measure your application with a profiler, when you
              find a bottleneck that is a native function call, and that
              function fits the critical() criteria, then apply the
              critical() linker option to that function, and if you
              actually see a performance improvement, then keep using
              it.</p>
            <p>Jorn<br>
            </p>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>