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