Question about Linker.Option.isTrivial()
Jorn Vernee
jorn.vernee at oracle.com
Sat Jan 13 11:27:52 UTC 2024
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/20240113/3fd39886/attachment-0001.htm>
More information about the panama-dev
mailing list