`@ccallable` allocates for its arguments

[vchuravy]

From https://discourse.julialang.org/t/gc-occurs-at-the-worst-time-in-tight-loop-garbage-collection/104934/82?u=vchuravy

Base.@ccallable function julia_set_dB_gain(dB_gain::Cdouble)::Cvoid 
    return nothing
end

f(x) = ccall("extern julia_set_dB_gain", llvmcall, Cvoid, (Cdouble,), x)


using BenchmarkTools

julia> @benchmark f(1.0)
BenchmarkTools.Trial: 10000 samples with 998 evaluations.
 Range (min … max):  16.092 ns … 230.391 ns  ┊ GC (min … max): 0.00% … 83.13%
 Time  (median):     17.305 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   18.390 ns ±   6.985 ns  ┊ GC (mean ± σ):  0.48% ±  2.21%

  ▂     ▆█▄▃▁▅                           ▁▃▂▁▁       ▁         ▂
  █▅▁▄▅▆███████▅▅▇▆▃▃▄▁▁▃▃▄▄▅▄▄▅▆█▇▇▆▅▅▄▄██████▇▆▅▄▅███▇▇▆▅▄▁▃ █
  16.1 ns       Histogram: log(frequency) by time      26.1 ns <

 Memory estimate: 16 bytes, allocs estimate: 1.

Where as @cfunction avoids the allocation:

julia> Base.@cfunction function julia_set_dB_gain(dB_gain::Cdouble)::Cvoid 
           return nothing
       end Cvoid (Cdouble,)
Ptr{Nothing} @0x00007fbbd0a4cff0

julia> f(x) = ccall(Ptr{Cvoid}(0x00007fbbd0a4cff0), Cvoid, (Cdouble,), x)
f (generic function with 1 method)

julia> @benchmark f(1.0)
BenchmarkTools.Trial: 10000 samples with 1000 evaluations.
 Range (min … max):  5.999 ns … 41.309 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     6.000 ns              ┊ GC (median):    0.00%
 Time  (mean ± σ):   6.049 ns ±  0.491 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  █ ▂                                                      ▂ ▁
  █▇█▅▄▄▄▃▃▁▃▃▃▁▁▄▁▁▃▁▁▃▃▃▁▁▁▄▁▃▄▁▁▃▁▁▃▄▁▄▅▆▁▄▁▁▄▁▄▄▃▁▄▃▁▁▃█ █
  6 ns         Histogram: log(frequency) by time     7.11 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

@vtjnash comment was: that is probably what @ccallable is supposed to do too

[rekabrnalla]

Any idea when this might be fixed, it causes a very messy interface for PackageCompiler.jl shared C-libraries? because @ccallable causes allocations. I just verified that manually getting the function pointer from the julia instance with jl_eval_string in my application does not have allocations. It would be nice for the @ccallable macro to provide the same performance.

[rekabrnalla]

This was marked as performance, but it really seems to be a bug. Anyone know how complex a fix this is?

[gbaraldi]

It's not trivial but also not too complicated. It requires setting up a trampoline for ccallable similar to how @cfunction works, currently ccallable does a plain apply_generic currently.

[rekabrnalla]

OK. Thanks for the help. I'm to green at this stuff to offer to help. I'm putting a link in my "Julia compiled" C-library interface readme.md to check back to this issue to see when it is resolved so I can remove the need for using jl_eval_String, and typedefs. It really makes Julia look a little weak in being able to be easily called from C and C++, so I'm hoping it goes away soon as we are evaluating the use of julia for real-time hardware testing and I can't have the GC cycles in the real-time loop. It's a tiny little thorn that could leave a bad taste for an otherwise pretty slick example, especially if programmers are evaluating rewriting julia code in C++ vs just compiling and calling the Julia directly.

[rekabrnalla]

Can we add the "bug" tag as well since this is not the way it should perform?
How can I help get this resolved? I'd like to utilize this in a demonstration of C real-time interoperability to my company and this could be seen as a "minus" on Julia's readiness level even though there is a work around. The whole point of utilizing Julia would be for less work by not rewriting Julia in C++, but if there are a lot of hoops to jump through, it defeats the point.

[gbaraldi]

This is not a bug technically, this is a performance issue ( a pretty big one). The issue here is that ccallable has to respect world age semantics and for that we do an apply_generic which means allocations. The better thing to do would be to implement a trampoline/function pointer that checks the world age and looks up a jl_codeinst_t global, if that is valid then we just call it, otherwise we would have to recompile that codeinst, annoyingly that has to be implemented using LLVM.

[rekabrnalla]

So, ideally because this macro is used to predefine functions in a shared library, everything would have been defined and compiled already, but it sounds like there is no way to guarantee that. I would ultimately like to ditch the re-compileability altogether and just have the c-equivalent library left over. But I concede there are more generic use cases. So the checking of the world age is causing the allocations?

[rekabrnalla]

I think ChatGPT explained it to me. The method you are proposing is going to remove the dynamic dispatch checking.

[KristofferC]

This looks fixed now (maybe by #57226)? Reopen if I am mistaken.

julia> Base.@ccallable function julia_set_dB_gain(dB_gain::Cdouble)::Cvoid 
           return nothing
       end

julia> f(x) = ccall("extern julia_set_dB_gain", llvmcall, Cvoid, (Cdouble,), x)
f (generic function with 1 method)

julia> using BenchmarkTools

julia> @btime f(1.0)
  3.916 ns (0 allocations: 0 bytes)

[rekabrnalla]

What Julia version did this go into. Will it be ported to 1.11?