<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><br></div><div>So, is there a simple way to both manipulate String with native memory and track the current memorysegment offset? If there isn't, I suggest this API should be added to the standard library for convenience.</div><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">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"><u></u>

  
  <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>