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