Question about Linker.Option.isTrivial()

[刘希晨]

@Maurizio Cimadamore <maurizio.cimadamore at oracle.com> Yeah that's exactly
what you have guessed, that MemorySegment.getString() only return a String,
but the caller don't yet know how many bytes they have read from the
current memorysegment, so further decoding won't know where to start.

I think it's a really common behaviour in network programming, like
ByteBuffer, recording the current message offset as its instance variable,
so the caller could use get() method multiple times without worrying about
its current offset, currently I wrapped MemorySegment in a ByteBuffer-like
structure for content reading and writing, but with
MemorySegment.getString() and MemorySegment.setString(), the afterwards
offset can't be obtained.

In my opinion, providing an API as `byte[] getStringBytes()` would be much
better for me, since I could just get the offset changed value as
`bytes.length`, and I can just construct the String using `new
String(bytes, charset)` myself, so that a dedicated record won't be needed.

Thanks and please forgive any mistakes in my English

Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 于2024年1月15日周一 20:26写道：

>
> On 15/01/2024 11:37, 刘希晨 wrote:
>
> 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.
>
> 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.
>
> 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).
>
> 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:
>
> * convert a Java string into a native segment, so that it can be passed to
> a native function
> * 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, ...
>
> 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?
>
> Thanks
> Maurizio
>
>
> 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/444bbcf5/attachment.htm>