Question about Linker.Option.isTrivial()

[刘希晨]

Thanks for your answers, that really helps.

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.

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.

Regards.

Jorn Vernee <jorn.vernee at oracle.com> 于2024年1月13日周六 19:27写道：

> On 12/01/2024 22:46, Maurizio Cimadamore wrote:
>
> On 12/01/2024 19:34, Pedro Lamarão wrote:
>
> ...
> May I suggest that the following be added to the Javadoc?
> It is already stated that it is advised that critical downcalls be
> "extremely fast".
> I suggest adding that they should run in a predictable, "constant" amount
> of time.
>
> I agree that the text could be improved - however we don't say "fast" - we
> say this:
>
> 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).
>
> I agree that talking about "constant" or "predictable" execution time
> would perhaps be a better characterization.
>
>
> This is what the "in all cases" is meant to convey. i.e. if in *some*
> cases the function doesn't have an extremely short running time, it should
> not be marked critical.
>
> 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.
>
> Jorn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240115/16d3f143/attachment.htm>