Question about Linker.Option.isTrivial()

[Maurizio Cimadamore]

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/245f9fbd/attachment-0001.htm>