Mark all CUDA ccalls as GC safe

[vchuravy]

Using https://docs.julialang.org/en/v1/stdlib/Profile/#Triggered-During-Execution I observed an issue in #2261 where
we acquire a lock in cuOccupancyMaxPotentialBlockSize and seemingly get live locked. Other threads
suspend in waiting for GC and no forward progress is being made.

Manually marking cuOccupancyMaxPotentialBlockSize as safe to execute GC next to seemingly fixes the issue,
we could add a convenience macro for doing this.

---

Update by @maleadt: I made all ccalls GC safe, made sure callbacks are GC unsafe again.

x-ref JuliaLang/julia#49933

[codecov]

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (38e28b7) 71.31% compared to head (9327071) 71.33%.

❗ Current head 9327071 differs from pull request most recent head 7067f9b. Consider uploading reports for the commit 7067f9b to get more accurate results

Files	Patch %	Lines
lib/cudadrv/occupancy.jl	37.50%	5 Missing ⚠️
lib/utils/call.jl	92.85%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2262      +/-   ##
==========================================
+ Coverage   71.31%   71.33%   +0.02%     
==========================================
  Files         155      155              
  Lines       14859    14893      +34     
==========================================
+ Hits        10596    10624      +28     
- Misses       4263     4269       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maleadt]

Pushed a macro version, and used that to mark all libcuda ccall's as GC-safe. I'm not confident this is allowed though, or at least not on all Julia versions, when doing a ccall that may call back into Julia.

Running the MWE from #2261 repeatedly on 1.8 doesn't seem to crash though.

[vchuravy]

I was debating if the try/finally was necessary and decided that it wasn't. Since we can only catch exceptions in gc_unsafe. cc: @vtjnash for a double check on that.

[vtjnash]

The try setup seems a bit risky to be present inside jl_gc_safe_enter, a catch/finally already implicitly reset the gc state upon leave (normal or error)

[maleadt]

The try happens after jl_gc_unsafe_enter?

[vtjnash]

Then I don't see how this is reachable, since cfunction already had to do an unsafe-enter to be able to dispatch into the runtime

[vtjnash]

Oh, I see this is for v1.8. That seems okay. I am surprised that is still supported here